mayo@ucbvax.ARPA (Bob Mayo) (10/11/85)
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.edudjb@riccb.UUCP (Dave J. Burris ) (10/11/85)
> 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.
ap@unido.UUCP (10/13/85)
try including osbind.h.
link like this:
[u] test.68k=gems,test,gemlib
link together with libf for floating point applications.
install program as *tos* or *tos taking parameters* application.
good luck!
Axel Pawlik
Univ. of Dortmund
( ...mcvax!unido!ap )peter@graffiti.UUCP (Peter da Silva) (10/16/85)
> 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.
simon@mcvax.UUCP (Simon Kenyon) (10/22/85)
because 16-bit ints are faster -- simon kenyon NSC, Dublin, IRELAND. simon@mcvax.UUCP