🚀 go-pugleaf

In article <3243@sdcsvax.UCSD.EDU>, jww@sdcsvax.UCSD.EDU (Joel West) writes:
> In article <2068@emory.UUCP., ospwd@emory.UUCP (Peter Day {EUCC}) writes:
> > From gatech!seismo!cmcl2!nyu-acf2.arpa!siritzky Tue Apr 28 11:44:13 1987
> >>>
> > 	... 	All of these C compilers
> > will only allow you a 32K code segment - for the whole program. In our
> > case this was way too little.
.....
> It is certainly possible to make programs with segments > 32K
> with MPW C.  The linker is quite keen on this, although any Macintosh 512
> will crash when it sees one.
> 
> I believe your data segment is still limited to 32K, though.

Macintosh Kermit, aka CKMKER 0.8(34), has a resource of type CODE and ID
1 which is 63078 bytes in length.  It has yet to crash my 512.  In fact,
this is a PARTICULARLY well-behaved program.  This program was created
by the sumacc C compiler at Columbia.  I don't know which combination of
68000 C compiler and assembler / OS is run on the machine which created
the program, or even what that machine is.  I think this establishes
that a code segment > 32k can run on the 512 (I think it runs on a 128, too).

In any case, let me throw in my two cents worth on this subject.  I have
been writing code for 68000 (Mac) and 8086 (Intel 310) for two years 
now, and have grown quite used to the idea of segmented code.  All of
the development systems I have seen allow either 32k or 64k code
segments, max, but they DO allow linking of several segments into one
main program.  I believe all the systems mentioned above for the Mac
can do this (correct me if I am wrong).  I do know that Lightspeed C
can be used to create large multi-segment applications whose total
code size is far in excess of 32 or 64k.

The idea behind segmented code, as I understand it, is this:  These two
processors use two general types of jump/call instruction.  There is a
16-bit offset jump, and a 32-bit offset jump.  The 16-bit offset jump
takes fewer bytes to implement, both for the "call" and for the
"return", but it is limited in scope to the size of a 16-bit
quantity--32k if signed, 64k if not.  Smart compilers, linkers,
programmers put closely related procedures in the same segment, and use
the long form of the instruction for less frequent procedure calls.
This is, of course, a simplistic explanation, I refer you to the
appropriate manufacturer's microprocessor handbook for details.

If you "go with the flow" and use segmentation for the purpose intended,
you can achieve significant savings in code size, execution time, and
development time.  There is programmer effort involved, true, because
you then have to decide which routines go in which segment (but that's
the kind of thing flow charts can help with.)  Segmentation on 16/32 bit
machines can be viewed in either of two ways:  It's a tremendous
inconvenience to the programmer.  OR It provides a convenient mechanism
to enforce intelligent, structured programming.  I guess it's all a
question of attitude.

As for the data segment, it is fairly simple to create more "data"
segments on the Macintosh by using custom resource types.  There are
also dynamic storage, separate files with data in them, linked lists, 
the data fork of your application, need I go on?

I hope this has been of some help.  If not, you could have hit the 'n'
key...
-- 
*********************************************************************
*Earle R. Horton, H.B. 8000, Dartmouth College, Hanover, NH 03755   *
*********************************************************************