blarson@skat.usc.edu (Bob Larson) (01/13/89)
In article <466@infovax.lan.informatik.tu-muenchen.dbp.de> mellin@lan.informatik.tu-muenchen.dbp.de (Reiner Mellin) writes: [in reply to my article on porting gcc:] >Well, With a modified CPP (decus or GNU) you can even bootstrap GNUGCC, >the only thing which is essential is the <long-line-bug> of the c68 (he >cant digest line which are longer than 512/1024? Bytes; I'm using microware C 2.2, osk 2.1 on a qt20x with 2.5 meg of memory. The version of gcc I started with was 1.22. (It takes me a day to get a new version via internet then kermit it to osk system.) I modified cccp (gnu's cpp) to output lines that c68 could handle. There are a few strings in gcc long enough that this won't always work, but it can be worked around. >I used the Version 2.2 of c68, and had to change only some enums inside >a structure). I don't remember any enum problems, other than the enum bitfields. (Microware doesn't have any kind of bitfields.) >>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 <sigh>. :-) How does your cpp handle the case of a quoted string longer than 512 characters? (I agree this problem can be worked around.) >> 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. The gcc I have has options for a couple of different kinds of 68k assembler, something close to microware's synax was one of them. The absolute addressing is a killer. >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 ). Other projects have moved to the forground for me as well. I'll get the latest version before I seriously resume the port. >> 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). Sounds like that microware is making progress with their cc. I may even get a new version in the neer future. >> 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 ??). It wasn't working in the version I started with, but it is now. There still are some arguement passing differnces, but most routines won't notice. >> 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 ?). I have osk 2.1. The problem is malloc fails (returns (char*)0) when there is still plenty of memory. Some files were fine, others ran into this. It seems that some strange usage pattern causes this problem. >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?). Writing assembly interfaces between gcc's calling convention and Microware's would be straitforword, and probably much easier than trying to port a different C library. -- Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%ais1@ecla.usc.edu oberon!ais1!info-prime-request