Xref: utzoo comp.sys.att:3580 unix-pc.general:888 Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!noao!arizona!naucse!rrr From: rrr@naucse.UUCP (Bob Rose ) Newsgroups: comp.sys.att,unix-pc.general Subject: Re: make bug, gcc stuff, ..., (No) more diffs (this time), LONG Message-ID: <752@naucse.UUCP> Date: 23 Jun 88 21:25:30 GMT References: <737@naucse.UUCP> <31200025@urbsdc> <1028@umbc3.UMD.EDU> Organization: Northern Arizona University, Flagstaff, AZ Lines: 82 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