ken@GATECH.EDU (Ken Seefried iii) (11/01/88)
TWIMC...
I would be interested in getting information on the 16-bit cross
compiler ports of gcc. Thank you...
ken seefried iii ...!{akgua, allegra, amd, harpo, hplabs,
ken@gatech.edu masscomp, rlgvax, sb1, uf-cgrl, unmvax,
ccastks@gitvm1.bitnet ut-ngp, ut-sally}!gatech!ken
"Children is more trouble than human beings!" -- Popeye the Sailorrfg@nsc.nsc.com (Ron Guilmette) (11/02/88)
Dear Ken,
Would you please summarize any (and all) responses you get about GCC as a
16-bit cross compiler to info-gcc. I may want to (or have to) do such a
re-target myself someday and I'd like to know how hard it is before jumping
in with both feet.
Specifically, I would like to know if anybody has succeded in convincing
GCC that int's and pointers are really only 16-bits wide on the target.
If so, I'd like to see some diffs for that.
Of course, the ideal thing would be to get GCC to have a command line
option which would tell it that ints & pointers should always be treated
as HImode values rather than SImode values. I can easily predict that
Dr. Stallman won't like it (targeting for brain-damaged 16-bitters that is)
but that's OK.
Another separate set of issues is raised by the thought of HOSTING GCC
on the quasi-16-bit 80286 (the 1 meg addressability limit on the 8086/8
is probably too small for GCC's needs). I may want to try this before
too long. I have convinced myself that I can do the bulk of the work
without even using a 286. Instead, I can start by using my favorite 32-bit
machine (a 32532 of course). All I have to do is:
1) use -Dint=short in the Makefile CFLAGS while building GCC
2) get out all the visible bugs which are revealed in step (1)
3) setup GCC's function preamble code so that it adds in a call to
an assembly routine called stkchk() which will have the same function
as Microsoft's stkchk() routine (i.e. checking that the stack has
not grown to more that 64KB) and make stages 1, 2, and 3 using this
altered preamble.
4) get out all the visible bugs which are revealed in step (3)
5) Add a command line option to GCC to get it to put (most/all) constant
data into the text segment(s) and make stages 1, 2, and 3 using this
option (so that the initial data segment is never more that 64KB).
6) get out all the visible bugs which are revealed in step (5)
7) Write a modified malloc() routine which aborts if the requested
block size is > 64KB and make stages 1, 2, and 3 with this malloc().
8) Get out all the visible bugs revealed in step (6).
9) Write a modified alloca() routine which will abort if the TOTAL stack
size exceeds 64KB after any single allocation.
10) Get out the bugs revealed in step (9).
---------------------------------------
After I have done all of the above steps, all I have to do is to:
1) Write the machine description files for the 286. (i.e. a re-target)
2) Get GCC to think that int's are 16-bits but that pointers are 32-bits.
3) Write a 286 alloca() routine.
4) Write a set of 286 (large model) malloc/realloc/free routines which
will allocate from extra data segments (always).
5) Bootstrap GCC on a real 286 using the above modifications.
----------------------------------
If you think that this won't work for some reason, I'd like to know why. I
think that this would be the best strategy for a 286 port, because I'd be
starting from a port that I already have confidence in.
Ron Guilmette
National SemiConductor, 1135 Kern Ave. M/S 7C-266; Sunnyvale, CA 94086
Internet: rfg@nsc.nsc.com or amdahl!nsc!rfg@ames.arc.nasa.gov
Uucp: ...{pyramid,sun,amdahl,apple}!nsc!rfgpaul@UUNET.UU.NET (Paul Hudson) (11/02/88)
[ Follow-up to making it work on 286 machines ] Memory usage will get you. On the Sun-3, it appears that cc1 needs 1.2Mb + for simple programs, non-optimising, more for large/complex programs. Anyone know where the space goes? BTW, I'm not complaining. I'm firmly in the school of thought which says do it right, not do it quick, or slow. Having said that I'm mildly surprised that non-optimising programs require that much room. Paul Hudson Snail mail: Monotype ADG Email: ...!ukc!acorn!moncam!paul Science Park, paul@moncam.co.uk Milton Road, "Sun Microsysytems: Cambridge, The Company is Arrogant (TM)" CB4 4FQ