Path: utzoo!censor!geac!torsqnt!hybrid!scifi!bywater!uunet!tellab5!toth
From: toth@tellabs.com (Joseph G. Toth Jr.)
Newsgroups: comp.sys.apple2
Subject: Re: C compilers
Summary: Might not be that simple...
Message-ID: <5069@tellab5.tellabs.com>
Date: 16 Jan 91 15:11:58 GMT
References: <378@generic.UUCP>
Sender: news@Tellabs.COM
Lines: 68

In article <378@generic.UUCP>, ericmcg@pnet91.cts.com (Eric Mcgillicuddy) writes:
> >> Basically, you are stuck with HyperC. You might consider rewriting the
> >Linker
> >Re-write the Linker??? Why in the world would anybody want (or need) to do
> >that?? It has worked just fine for for every compile i have performed.
> 
> Rewriting the Linker is required to generate stand alone SYS applications
> under prodos. HyperC assumes the OPSYS file to be present during execution and
> links it in as a runtime library (soft links?). If OPSYS is not present, then
> the linker must attach all of the functions normally provided by it.

This isn't necessarily so..

I guess things never are as simple as they sound, but rewriting the
linker would only be the beginning of more and possibly bigger problems.

Remember; P-code object files and Native code object files link together
and execute fine.  The 'BRK' 6502 op code invokes the interpreter for
code immediately following the break (until the P-code routine returns).
How many (anybody care to guess??) supplied routines are written using
P-code?  How many were compiled (My guess is none, [scan the SYM output])?
How many are compiled using the assembler?

People sharing code (who don't wish to part with source) could post linkable
objects (ie. a 'curses' set of functions in a library), where some object
files are P-code. Try linking and executing those without the 'opsys' ;^).

One option would be a program that in some way converts any executable
into a new file that contains both the opsys (modified to not load 'SHELL',
then execute the shell as if it were loaded) and the target executable (at
the appropriate location).  This would eliminate any potential problems
of linking objects of differing types.

It would also be possible to simply change the filetype of the HyperC
executable to SYS, and then overwrite the lead in code (prior to the first
6502 code in the s.o file) with NOPs.  This would require a re-write of
the s.o object file to perform all appropriate tasks (pseudo stack init,
I/O buffer inits, etc) previously handled by opsys.  Also, many system
functions (printf, xprintf, alloc, free, file I/O, [many more]) that were
anchored to opsys, will have to be supplied.  Luckily, once they are made
available, simply replacing the objects (which contain anchoring information)
in the LIBC library will cause no linker problems.

One other problem with links that can be native code only..
The floating point package has major problems when compiled to
native code, but seems to operate OK (in the checks I have done)
when executed as P-code elements.

> Native compiles do not need the p-code interpreter, so this could be
> discarded, but otherwise, most of OPSYS will be used by most applications.

Remember, just because you compiled something into a native code object,
don't assume that everything you link to is native code also (:^j)

> Floating point is handled by SANE, I have no idea why they do not work under
> native compiles. Have you tried the log.c example included on the /fp disk?
> See if this works.

Seems to be more inSANE when compiled to native code ;^)

Question;
Does c.system (and gs.system) actually overwrite a portion of its own code
with opsys, and then fall into it (opsys) via normal execution?

--
------------------------------------------------+---------------------
Maybe I shouldn't have done it, sarcasm is so   | Joseph G. Toth Jr.
seldom understood.  Don't FLAME on me, please.  | uunet!tellab5!toth