Path: utzoo!attcan!uunet!mcvax!unido!ztivax!tumuc!lan!mellin From: mellin@lan.informatik.tu-muenchen.dbp.de (Reiner Mellin) Newsgroups: comp.os.os9 Subject: Re: Soapbox ramblings (long) Summary: can be done in time Keywords: GNU GCC GDB public domain Message-ID: <466@infovax.lan.informatik.tu-muenchen.dbp.de> Date: 10 Jan 89 02:05:52 GMT References: <3979@tekigm2.MEN.TEK.COM> <1196@mmm.UUCP> <14338@oberon.USC.EDU> Reply-To: mellin@lan.informatik.tu-muenchen.dbp.de (Reiner Mellin) Organization: Inst. fuer Informatik, TU Muenchen, W. Germany Lines: 98 [sorry for answering so late, but out vax didn't get news over Xmas time :-)), don't read new but celebrate ?] In article <14338@oberon.USC.EDU> blarson@skat.usc.edu (Bob Larson) writes: >In article <1196@mmm.UUCP> schultz@mmm.UUCP (John C Schultz) writes: >>How about porting GNU compilers etc. for OS9? The price is right - free. > >Actually, I have started playing with such a port. Microware's C (2.2) >realy isn't up to handling the bootstrap. Well, With a modified CPP (decus or GNU) you can even bootstrap GNUGCC, the only thing which is essential is the of the c68 (he cant digest line which are longer than 512/1024? Bytes; i fixed the decus cpp that he will emit a when outputting a line bigger than 400 Chars, which will happen with this LOOOONNGGGG GNU-macros). I used the Version 2.2 of c68, and had to change only some enums inside a structure). >>We have compiled code on SUN and downloaded to standalone 68000s which >>run OS9 so the changes should be minor. > >I actually have Gnu cpp (cccp) running. Here are a few examples of >"minor": > Gcc uses looooooooong lines. Microware C chokes on 512 >characters, some gcc macros ten times that, and some constant strings >are longer as well so simple line breaking isn't enough. with the newst version of my port of the decus-cpp (will be on TOP Release 2 in source :-)), you can forget that problem . :-) > Gcc gobbles memory. I doubt it will ever work on a system >with less than a megabyte. Yep, about 380kb of code and the same amount of dynamic memory. > Gcc has no apperent way to generate code without absolute >addresses. THe MAIN POINT !!! I got GNU-GCC up and running, but it generated sun-assembler with *absolute* addressings. I suspended the Porting since my Version was too old (1.18) and i got Version 1.31.(But, i have no time at the moment ). > Gcc uses structure valued functions, bit fields, void, and >other features not yet present in Microware C (as of 2.2). that was not a problem (i got an intermediate version of 2.2, between orig. 2.2 and 3.0). > Gcc's argument passing does not match Microware's. > Gcc assumes a unix library is available. well, the older Verion i used (1.18) couldn't pass parameter in registers, the newer Versions of GCC seems to be able to do that (influence of sparc-port etc ??). > Microware's malloc is broken, and cccp exersises the bug. nver experienced that on my Osk-2.1 .....(a problem of 2.0 or its library ?). >>It would be nice if Microware realized that they are wasting their >>time with their C compiler/debugger and simply began supporting GNU >>GCC and GDB. I would think such a decision would actually save them >>money since GCC is already better (e.g. GCC correctly compiles >>floating point and complex function calls) than the OS9 C compiler. >>OS9 would then also have a C++ compiler in the form of G++. > >It might save them money, but it would not directly make them money >either. Since Microware is in the software business, I don't expect >them to do this. neither me, but a real full-fledged compiler (and C++) would be fantastic (at an REASONABLE PRICE !!!!!). >Well, if anyone wants a outdated but mostly-working osk gnu cpp, and >will continue the project... The State of my `Port': - GCC compiles under OSK and generates sun-asm--output with *absolute* addressings. - the compile-speed is comparatable to the duo c68/o68 but need far more memory ! - The generated size is about 30% smaller and 20-30% faster than microwares (hand-translation of sun-asm.ouput to microware-asm). So, There are Two major steps to take: - getting GCC output *relative* addresses instead of absolute. - if the parameter passing in registers fails, a new clib have to be written (maybe we can adopt the Library of the ST-port of GCC? or the MINIX-port?). optimistic Greetings Reimer Mellin -- | Reimer Mellin | mellin@lan.informatik.tu-muenchen.dbp.de | | Sulenstr. 8 | pyramid!tmpmbx!ramsys!ram (home) | | D-8000 Muenchen 71 | Technische Universitaet Muenchen |