From: d88-jwa@dront.nada.kth.se (Jon Wtte)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Sozobon (or other free C's): would this strategy work?
Date: 5 Jan 93 10:09:29 GMT
Distribution: comp
Organization: Royal Institute of Technology, Stockholm, Sweden

In <29879@castle.ed.ac.uk> ngse18@castle.ed.ac.uk (J R Evans) writes:

>programming is understanding what those times are).  Fortunately,
>even in the Mac world, some things have to stay constant, and there
>are ways to pin things down in memory.  Doing so is considered Bad
>Form in Cupertino, and what I am going to propose involves locking

Not necessarily; if you start locking a LOT of things down, you
will start fragmenting the heap (much as you fragment a hard disk)
which leads to bad performance and you run out of contiguous space.
If you lock down, say, two large blocks, MoveHHi-ed, at the start
of execution (before any memory is allocated) you won't burn in
hell, only get a few years in purgatory.

>time.h etc.  Life is even easier if we are only planning to implement
>a K&R compiler!  In the first instance we need build afresh only the

People using this compiler would be beginners mainly, and they go
out and buy a "learn C" book. Almost all of them use ANSI style
functino prototypes.

>Support for A5 globals (particularly those needed by QuickDraw and 
>friends) is probably the messiest part of all this; hopefully, the
>original application A5 could be stored by the loader in a well known

Better would be to just tell the compiler to leave A5 alone. Since
it probably already does that with A6 and A7, do the same for A5.
Then have the CODE 0 resource contain a pre-defined quickdraw globals
area, and you should be all set, and avoid a LOT of messiness. What
would you, for instance, do about callbacks else?

>of execution!  Even worse, in the simple scheme presented above, the 
>relocation information is left lying around uselessly, trapped within
>the CODE 2 resource locked in memory.  

That's no problem; if the relocation information is at the end
of the area, just SetHandleSize() it away (before locking the
block)

Or make the compiler emit the relocation information separately.
Or just have the "mac-linker" divide it out into another resource.

>Mac extensions are likely to cause some grief, but again I'm not
>convinced that that will be insufferably great.  Things like the \p
>pattern for Pascal strings could be a bit of a nuisance, and I don't

\p is important, but even more so is the pascal calling keyword.
It is used for callbacks from the toolbox (for things like modal
dialog filters, file filters, AppleEvent handlers, ...) as well
as used by the headers - and it requires the compiler to push the
arguments the other way around!

>Finally, for the moment at least, Sozobon does not emit MacsBug symbols.
>This will be a pain for the initial implementors, but I can't believe
>that it would be any kind of big deal to fix up.

macsBug symbols are really Very Easy(tm). Just trap emitting an
RTS and add the data for the symbol.

However, this looks like something that would take a talented
hacker a year to do. You had better get started...

Cheers,

							/ h+

-- 
 -- Jon W{tte, h+@nada.kth.se, Mac Hacker Deluxe --

   Cookie Jar: Vanilla Yoghurt with Crushed Oreos.