Path: utzoo!telly!ddsw1!lll-winken!killer!osu-cis!tut.cis.ohio-state.edu!nsc.nsc.com!rfg
From: rfg@nsc.nsc.com (Ron Guilmette)
Newsgroups: gnu.gcc
Subject: Re:  16-bit x-compiler ports
Message-ID: <8811012140.AA06720@nsc.NSC.COM>
Date: 1 Nov 88 21:40:05 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 76

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!rfg