walls@killer.DALLAS.TX.US (Monty Walls) (05/28/89)
--------------------------------------------------------------------------
What CPU's are supported by GCC? What CPU's will be supported
in the near future? If someone would mail me the list I'd
appreciate it.
Thanks,
-Monty Walls
--------------------------------------------------------------------------
Monty Walls
Work: Home:
MIS Division, Tech. Support 2224 Houston Apt #8
Oklahoma Tax Commission Norman, OK, 73071
2501 N. Lincoln USA
OKC, OK, 73194 Phone - 405-364-5123
USA uucp - killer!walls
Phone - 405-521-4300schmidt@ics.uci.edu (Doug Schmidt) (05/29/89)
In article <8216@killer.DALLAS.TX.US> walls@killer.DALLAS.TX.US (Monty Walls) writes:
++
++ --------------------------------------------------------------------------
++
++ What CPU's are supported by GCC? What CPU's will be supported
++ in the near future? If someone would mail me the list I'd
++ appreciate it.
This is from the GNU bulletin:
----------------------------------------
CPUs supported include the 680x0, Vax, 32x32, 80386, Sparc (Sun 4), SPUR
and Alliant. Ports for the Convex, the IBM 370, the IBM PC/RT, the 3b2,
some sort of Gould machine, the HP Spectrum, the AMD 29000, the MIPS
RISC chips, and the Motorola 88000 are on their way.
----------------------------------------
Doug
--
On a clear day, under blue skies, there is no need to seek.
And asking about Buddha +------------------------+
Is like proclaiming innocence, | schmidt@ics.uci.edu |
With loot in your pocket. | office: (714) 856-4043 |schwartz@shire.cs.psu.edu (Scott Schwartz) (05/29/89)
In article <16049@paris.ics.uci.edu>, schmidt@ics (Doug Schmidt) writes: >Ports for the Convex, the IBM 370, the IBM PC/RT, the 3b2, >some sort of Gould machine, the HP Spectrum, the AMD 29000, the MIPS >RISC chips, and the Motorola 88000 are on their way. Speaking of the RT, who is working on that port? If they want beta testers, I volunteer. -- Scott Schwartz <schwartz@shire.cs.psu.edu>
dsmythe@cup.portal.com (dave l smythe) (05/30/89)
What about the DG Eclipse?
raeburn@athena.mit.edu (Ken Raeburn) (05/30/89)
In article <4622@psuvax1.cs.psu.edu> schwartz@shire.cs.psu.edu (Scott Schwartz) writes: >Speaking of the RT, who is working on that port? If they want >beta testers, I volunteer. I am one of the people who have been working on it; however, it doesn't fully work, and I haven't had the time to do much lately. There's also a version Richard Kenner of NYU has been working on, which is a lot more oriented towards optimization than mine, but (I believe) also doesn't fully work. I've got a copy of his code and was intending to isolate the gcc changes needed for getting it running (as opposed to the instruction scheduling, which is nice but not necessary, and I think someone else is working on that anyways) and just try to get it running, but haven't been able to get the time. If anyone wants to hack on these, let me know.... -- Ken Raeburn MIT Project Athena
meissner@DG-RTP.DG.COM (Michael Meissner) (06/10/89)
In article <18930@cup.portal.com> dsmythe@cup.portal.com (dave l smythe) writes: | What about the DG Eclipse? Oh boy, a subject for which I'm qualified to digress on. I'm one of the few people (I believe) that has actually worked on compilers for the DG computers as well as GCC (for the 88000). I'm not aware of any ports to either the Eclipse (16 bit) or the MV/Eclipse (32 bit). In my opinion, this would be painful, for the following reasons: If you really meant Eclipse as opposed to MV/Eclipse, GCC has a definite 32-bit bias in it. The compiler itself would never fit in a 16 bit address space, IMHO. The Nova, Eclipse, and MV/Eclipse is one of those 'fun' word based machines, which have different pointer formats for pointers to bytes and pointers to words. GCC internally believe there is only one true pointer format. This can be gotten around by always using byte pointers on the DG side, and doing the conversion before dereferncing it. Another 'fun' ascpect to the traditional DG computers is that it only has four registers, and only two of the registers can used to dereference word pointers. You could concievably write the appropriate macros in the machine dependent portion of GCC, but I suspect some of GCC's algorithms for register allocation and spilling might be inappropriate for so few registers. Another gotcha is that the stack pointer, frame pointer, et. al don't normally reside in fixed registers. Finally, the traditional DG/CLRE calling sequence for the Eclipse (but not the MV/Eclipse) pushes a pointer to hold the return value if the function returns a value, but does not push that pointer argument for void functions. You would have to make sure that all void functions are declared as such in the scope of any calls, or not use the DG/CLRE calling sequence (which is what I recomend). However, if you have plenty of time on your hands, go to it. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner If compiles were much Internet: meissner@dg-rtp.DG.COM faster, when would we Old Internet: meissner%dg-rtp.DG.COM@relay.cs.net have time for netnews?