🚀 go-pugleaf

> Has anybody gotton any non-AES&VDI programs to run on the ST?  Even
> the following program bombs for me:
> 
> 	#include <stdio.h>
> 	main()
> 	{
> 	}
> 
> I'm linking it with gemstart.  I've also tried it with gems.  Anybody
> out there know what is wrong?
> 
> --Bob Mayo
> 
> 	...!ucbvax!mayo
> 	mayo@ucbkim.berkeley.edu

Try this:

	link68 [s,u] gemstart,PROG,gemlib,libf

I think that's all of them. I've managed to get a simple program that reads
the MIDI port and prints the hex byte to the screen working. The libf library
resolves the atof() and etoa() undefined errors. 

You also have to be careful when passing arguments because the C compiler
does not automatically convert everything to long words when passing arguments
on the stack. chars and ints use MOV.W data,(SP)- and pointers and longs
use MOV.L data,(SP)-. This can can a crash due to bus errors because if
you're not careful you could pick up an invalid pointer.

Don't ask me why they decided to do it this way, probably just to cut down
on generated code and improve speed, but it definately will cause problems
with LOTS of software that assumes that arguments passed to function are
the same size and resized to the proper size by the called function.

-- 
Dave Burris
..!ihnp4!ihopa!riccb!djb
Rockwell Switching Systems, Downers Grove, Il.

> You also have to be careful when passing arguments because the C compiler
> does not automatically convert everything to long words when passing arguments
> on the stack. chars and ints use MOV.W data,(SP)- and pointers and longs
> use MOV.L data,(SP)-. This can can a crash due to bus errors because if
> you're not careful you could pick up an invalid pointer.
> 
> Don't ask me why they decided to do it this way, probably just to cut down
> on generated code and improve speed, but it definately will cause problems
> with LOTS of software that assumes that arguments passed to function are
> the same size and resized to the proper size by the called function.

There is certainly precedent for this sort of thing: the original Ritchie
compiler did things this way. If your code assumes that int promotes to long
or to (void*) on a function call it will die on more machines than just this
one.

Now why they didn't follow the VAX' precedent and make ints 32 bits, and shorts
16 bits, I don't know. Are you sure that the compiler uses 16-bit ints? Strikes
me as silly on a 68000.

because 16-bit ints are faster
--
simon kenyon
NSC, Dublin, IRELAND.
simon@mcvax.UUCP