Path: utzoo!attcan!uunet!husc6!endor!singer
From: singer@endor.harvard.edu (Rich Siegel)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Flex fast lexical analyzer for MPW announcement.
Keywords: %Globaldata Sucks Wind.
Message-ID: <4636@husc6.harvard.edu>
Date: 23 May 88 11:38:56 GMT
References: <8534@dartvax.Dartmouth.EDU> <10896@apple.Apple.Com> <6645@cit-vax.Caltech.Edu>
Sender: news@husc6.harvard.edu
Reply-To: singer@endor.UUCP (Rich Siegel)
Organization: Symantec/THINK Technologies, Bedford, MA
Lines: 62

In article <6645@cit-vax.Caltech.Edu> wetter@tybalt.caltech.edu.UUCP (Pierce T. Wetter) writes:
>In article <10896@apple.Apple.Com> dan@apple.UUCP (Dan Allen) writes:
>>I agree that a 32K global data limit is stupid.  But the workaround in
>>most cases is so trivial (especially in C) that why waste time worrying
>>about it?  USE THE HEAP!  If a program needs big buffers or big arrays,

	Ditto!

>  lex, gnuchess, yacc, bison etc. were originally written assuming there was
>  infinite memory. When you don't really understand what the code does (which
>  I didn't with bison, I just replaced array declartions with malloc) its a
>  pain to go back and find ALL large array references and fix them.

	I'm sorry, but that's a fundamental problem when porting mainframe
programs to microcomputers. I am not unsympathetic to your problem, because 
I've done it many times myself, and learned the hard way. Assuming that you
have infinite amounts of core to play around with is simply not valid.
You can't get something for nothing...

	When it comes to large constant data tables, the solution, while not
effortless, is nearly so. Take your initialization statement, and make the
necessary calls to allocate a big enough handinitialize the handle
with this data, and write it out as a resource. Then your program simply
needs to load in this resource at initialization time. (For ann added bonus
you can mark the resource as preloaded and locked, so it goes very low in
the heap - right above the master pointer blocks.) This is much faster
than initializing all that data...

	I'm using this technique in an iversion if PEditof PEdit (the
sample editor that goes with Capps Prime) for keyword tables (for boldfacing
Toolbox calls)) and it works beautifully for me.

>  ABOVE ALL, 32K IS HALF AS MUCH AS THE LIMIT SHOULD BE. Whoever is in charge
>  of writing linkers for Mac compilers could instantly double the amount of 
>  global data simply by pointing A5 at the MIDDLE of the global data 

	It's an interesting idea, but since I'm not writing the linker, all
I can do is pass the suggestion along (and it's also a cochange that
needs to be made. I think.).

	By the way, it's worth noting that LightspeedC places no limit on
the amount of string and floating-point constants that you can declare, which
helps somewhat...

>  Are you listening Apple, Think?

	Always. :-)

		--Rich

CAVEAT: I'm not a compiler or linker writer, just a wimpy user interface
kinda guy. :-)




Rich Siegel
Quality Assurance Technician
THINK Technologies Division, Symantec Corp.
Internet: singer@endor.harvard.edu
UUCP: ..harvard!endor!singer
Phone: (617) 275-4800 x305