make bug, gcc stuff, ..., (No) more diffs (this time), LONG

[Bob Rose]

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