lalonde@torolab2.vnet.ibm.com (Glen Lalonde) (03/15/91)
I pulled the binaries for gcc and related utilities off plains.nodak.edu and yes they do work with MacMinix. MacMinix does use a special version of crtso.o but this is only needed if you want to call the Mac system routines. As for performance, this is what I get for dhrystones: Ack compiler 360, c68 416, gcc low opt 520, gcc high opt 560.(Mac+) If I remove the NOSTRUCTUREASSIGN(something like that) define in dhrystones that numbers for gcc -O are about 700. I was hoping that gcc -O would give me much better numbers that that, are these numbers typical for gcc -O in terms of the % speedup given at -O? I guess the only things one has to look out for when using gcc -mshort is sizeof, change sizeof() to (int)sizeof() and the use of setjmp/longjmp. Possibly read-only strings. Is this correct? Many thanks to Andrew J Michael for doing the port.
lalonde@torolab2.vnet.ibm.com (Glen Lalonde) (03/25/91)
A few questions have come up about GCC and MacMinix, so here is what I know. I just pulled the binaries off plains and installed them and have had no problem with the setup, but I did need a chmem to 1.2MB or more for gcc-cc1 to compile a large program at high-opt. Now for the good stuff: I tried to compile the MacMinix OS with gcc and found that when I tried mm it compiled ok, after a patch to head.s, but when I ran the OS it gave a MM Panic "kernel did not respond to get_mem" when it booted. I checked and the sendrec in getmem was getting -10 back, which means something like no children??? Next I tried to compile up FS, this went well. I tried to boot it with a ack build mm and kernel. The result was a crash at just before INIT in memory, so I just used macbugs to start at the init start location and all went well. Now I did this many times and what allways happens is it crashed at about 9exyy where yy !=0 but INIT always started at x+1 yy==0. Thus it was easy to restart, and the initial boot screen always did have the correct address of init. After a while a hacking I found that the default for gcc was ansi mode ie __STDC__ =1, but if I compile fs/main.c with -traditional (ie no prototypes) the gcc built FS worked!! :-) This was a low-opt compile, I have not tried high-opt yet. As far as I can tell the FS runs ok and it never crashed on me yet(after using -traditional on main). I have yet to try the kernel, and don't indent to do so until the patches for the kernel are posted since I have found out that most problems in the kernel, including the slowww screen scroll have been fixed in the update to be posted soon(I hope) by Joe Pickert. Lastly I noticed that when sys_abort is called(in panic) it crashed my mac, does this libc routine have some MAC specific stuff in it? Since I am using the libc.a(st-version) that comes with gcc I guess sys_abort will not work. If anyone has a GCC MacMinix MM working let me know how you did it.
Glen Lalonde <lalonde@torolab2.vnet.ibm.com> (03/29/91)
I reported that using -traditional on main.c of fs would get around the problem of using a gcc fs. This is not true, the real problem is with the options sent to ld. You may notice that for the normal ack build of fs the options -a0:256 -a1:256 ... are used this will cause the data and code section to be padded to a multiple of one page. Now this is not done for gcc-ld and thus in the kernel where is tries to find the location of init, after cutting off the last eight bits of the size(assuming its just zero), the wrong location is found. The fix will be to change kernel/(cstart.c main.c) not to remove the last eight bits OR tell gcc-ld to do the padding also. Does anyone know what gcc-ld option has the same affect as the -a0:256 send to the ack ld?
Glen Lalonde <lalonde@torolab2.vnet.ibm.com> (04/01/91)
I now have a working gcc compiled fs and mm, done without any kludges this time. The basic problem with using gcc to compile fs and mm is the size of the text and data section both must be a multiple of 256. I could find no gcc-ld option to force this. After attempting about five different hacks, including altering the kernel I have come up with a decent method around the problem. Compile fs and mm with gcc, do a size on them. Note how far the text and data sections are from a multiple of 256, alter end.s to have .fill amountOff,1,0 then re bind. Thus you get a text and data section that are padded. This works and requires no kernel hacks. You will need to change head.s for mm to bind, since it has a special routine in it that does not come with the standard gcc head.s My gcc MacMinix has been working for a few day with no problem. Next ...the kernel.. A quick test showed cat file > /dev/null going 15% faster. Sorry about bashing c68, I had just finished debugging my problem with it when I posted my message about the bug. MacMinix for now only supports 24bit addressing, so forget about using system 7 to get 20MB. See kernel/cstart.c and main.c O yes, ps breaks with gcc fs and mm. gcc-ld pads identifiers with blanks! Thus ps can't find _fproc You will need to alter nlist.c to fix this, it is about a 10 line change and I have a nlist that will now work for gcc and non-gcc compiled programs. Want it posted?