rrr@naucse.UUCP (Bob Rose ) (06/24/88)
First I would like to apologize to alex. I am the one that first posted the gcc-1.22 diffs. In them I left the address to post bugs and so on to alex. Any problems with applying those diffs should be sent to me. Alex, if you where swapped with mail, I am sorry. He had no clue that I was gonna post some diffs. Also if you have any problem getting up gcc in general, I will be more that happy to help. One more time: Alex was the first to port gcc to the unixpc, I just fixed a few typo's in the 1.22 version. ******************************************************************************* >I write: >>Note the kernel has a bug in it (what AT&T produce something buggy, >>never ;-) so if for some reason the make blows up (usally you see > > This isn't a kernal bug, it's a bug in make. [...] I still haven't tracked it down (-: does it depend on the phase of the moon :-) but has anybody ported a pd make. There is gnu-make but it is so BSD dependent that porting BSD would probably be faster. ******************************************************************************* >Regarding the _mulsi(), etc library calls: > > I think that the solution to this is to create a header file with >the integer math routines coded in assembly, and declared 'inline'. ... I've >collected some fast integer math stuff in 68K assembly, and will be happy >to forward what I have to anyone interested. This won't work as far as I can tell. When gcc parses c code it generates a call to _mulsi3 whenever it sees an int multiply. Now that this is a function call, gcc is stumped on how to optimize it (it may have side effects and so on.) You can inline a c function but I don't think you can inline an intrinsic. Also mark me as interested as having the 68k assembly. ******************************************************************************* > >About the diffs that were posted: > > This is ment as constructive critisizm, and I hope that it is taken >as such. The diffs that were posted contain a *potential* bug ... No problem, constructive critisizm is always welcomed. I should point out that I tried to `bring out this bug.' When I couldn't I posted the diff's so the people on the net could get it up. Until gcc gets register scoring or something of that sort (which won't help the 68k verison) I don't think this potential bug will ever show up. Now I would like to bring something to you attention. You have gcc produce swbeg &5 L129: short 0 # this is for the offset calculation ... set LD129, L129-LI129 You can lose the `short 0' place holder by changing the set to be set LD129, L129-LI129-2 It saves a whopping 2 bytes per case table :-) Also in internal names and labels there should be a `%' so that they will never be confused with global c names (extern's and functions) The following may cause gcc to produce assembly that will crock without this confuse1() { static int confuse; } confuse2() { static int confuse; } (it is something like this, I lost the true example) -bob Robert R. Rose Northern Arizona University, Box 15600 Flagstaff, AZ 86011 .....!ihnp4!arizona!naucse!rrr