[net.micro.amiga] Desperation

dgg@ci-dandelion.UUCP (Dave Grubbs) (11/03/86)

I am a 4.2/4.3/Ultrix kernel hacker.  In the past 8 years, I have
written nearly .5M lines of code in 16 languages (incl.  6 assembly
languages).  I mention this to indicate that I know what computers and
compilers are.  The Amiga was bought to learn 68K assembly, to store
personal data, and to hack on visual, sound, and control programs.  I
enjoy hacking, so I started compiling the Fish sources, some Unix
programs and some programs of my own. 

I have purchased both compilers, Lattice (bacause I didn't know any
better when I first got my Amiga) and Manx (so I don't have to "port"
every program the Manx hackers write). 

Enough background.  I have a serious problem.  Though every commerial
program (including the compilers) and every Fish disk executable seem to
run just fine, every program bigger than "Hello World", that *I* have
compiled, fails with one of 5 damn GURU messages. 

The one which finally got me is the "cc" program on Fish disk #29.  I
compiled it with Manx, using "cc cc.c" and "ln -o cc cc.o -lc" (I know
about CLIB and ram:) and it compiled with no errors.  When I execute
it, the system hangs.  CTRL-Amiga-Amiga has a 50% chance of showing a
GURU at this point.  I put "printf's" in and sometimes they show up and
sometimes they don't. 

Well, what I am really asking for is what these damn things mean or how
to find out myself.  I haven't seen any mention of GURU, other than
obliquely, since I started reading this news group:

	#00000003.00004F92
	#00000003.000097B0	(A favorite -- it shows up EVERYWHERE)
	#00000004.000027D2
	#84000009.48454C50	("HELP"?  I had guessed these were addresses.)
	#0000000B.2C6DFFFC

Could I have my hardware set up wrong?  (Then why does every executable I run,
that was not created on my machine, work just fine?)  Could I be missing some
important compiler switches?  (Then why do the makefiles provided with the
Fish sources do no harm to anyone else? -- Remember, I have both compilers.)

I have tried the dealer, but they don't seem to care about the Amiga any more.
In any case, they don't have any hackers, just sales types.
If I can't get help from the net, this frustrating monster is going out the
window.  I'll scrape enough money together to go buy a Sun or a microVAX.

higgin@cbmvax.commodore.COM (Paul Higginbottom) (11/05/86)

In article <201@ci-dandelion.UUCP> dgg@ci-dandelion.UUCP (Dave Grubbs) writes:
>...explains his VERY extensive programming background.
>The Amiga was bought to learn 68K assembly, to store
>personal data, and to hack on visual, sound, and control programs.  I
>enjoy hacking, so I started compiling the Fish sources, some Unix
>programs and some programs of my own. 
>
>I have purchased both compilers, Lattice (bacause I didn't know any
>better when I first got my Amiga) and Manx (so I don't have to "port"
>every program the Manx hackers write). 
>
>Enough background.  I have a serious problem.  Though every commerial
>program (including the compilers) and every Fish disk executable seem to
>run just fine, every program bigger than "Hello World", that *I* have
>compiled, fails with one of 5 damn GURU messages. 

I have had the SAME problems with most of what I have received "through
the grapevine" so DON'T FEEL ALONE!

>The one which finally got me is the "cc" program on Fish disk #29.  I
>compiled it with Manx, using "cc cc.c" and "ln -o cc cc.o -lc" (I know
>about CLIB and ram:) and it compiled with no errors.  When I execute
>it, the system hangs.  CTRL-Amiga-Amiga has a 50% chance of showing a
>GURU at this point.  I put "printf's" in and sometimes they show up and
>sometimes they don't. 

Most of the fish source (I may get flamed for this) PROBABLY requires
you to compile with 32 bit ints (if using Manx).  This means using the
+l option of the compiler, e.g:

	cc +l cc.c

And linking with the 32 bit version of the link library, e.g:

	ln -o cc cc.o -lc32

This SHOULD clear up some of your problems.  HOWEVER, be warned about
lousy code.  The memory display program from Amiga no less bombed my
machine when I compiled it.  Only then did I see a comment in the source 
(thanks a lot RJ) which said something like "oh by the way, cuz of the neat
way I did this, it will croak if you have more than 512K memory".

Next potential problem in Lattice which I've seen mentioned a lot on here,
(although I should point out I'm not a Lattice user or fan), is linking
with the right startup object code.  Apparently there's one blessed by
Amiga, and another by Lattice (astartup.obj vs lstartup.obj, I think).

Regarding the 32 bit vs 16 bit problem - if you must use 16 bits (I do
for everything because of the small code size and faster executables it
produces) make sure EVERY PARAMETER PASSED TO ANY SYSTEM CALL IS LONG!!!!!

Believe it or not, they assume everything on the stack MUST be 32 bits,
even if its a character, a short, whatever.  For example, AllocMem bit me
in the private parts a few times until I realized that sizeof() under 16
bits will yield an INT which is 16 bits and must be cast to a long.  E.g:

	ptr = AllocMem(sizeof(struct foo));
	^
	|
	brain death under 16 bits.

	ptr = AllocMem((long)sizeof(struct foo));
	^
	|
	better.

>Well, what I am really asking for is what these damn things mean or how
>to find out myself.  I haven't seen any mention of GURU, other than
>obliquely, since I started reading this news group:

Try reading the albeit cryptic include file <exec/alerts.h>.  This might
shed some light on the gurus.

>	#00000003.00004F92
>	#00000003.000097B0	(A favorite -- it shows up EVERYWHERE)

The "3" errors are addressing errors, i.e., your program (or a paremater
you passed to a system call) is trying to address something out of range.

A common cause for these problems is lousy programs that interchange
ints with pointers, and you then compile under 16 bits and KABOOM.

Also, no checking for null returns in calls, alloc failure, incomplete
initialization, etc... all can cause addressing errors.

>	#00000004.000027D2

The "4" errors are caused by trying to make the processor execute an
illegal instruction.  Probable cause related to above.

>	#84000009.48454C50	("HELP"?  I had guessed these were addresses.)

This is caused by specifying a bad screen type when trying to open one.  I
guess neither CUSTOM nor WORKBENCH.

>	#0000000B.2C6DFFFC

This means complete braindeath - a B is for one of the processor emulation
lines being hauled about.

>Could I have my hardware set up wrong?  (Then why does every executable I run,
>that was not created on my machine, work just fine?)  Could I be missing some
>important compiler switches?  (Then why do the makefiles provided with the
>Fish sources do no harm to anyone else? -- Remember, I have both compilers.)
>

I believe I may have shed some light on the reasons, but if you had flakey
hardware, I doubt Exec etc. would run.

I think a lot of the public domain stuff is for Lattice (since it was out
first), but using the 32 bit options on Manx usually suffices to produce
similar results.  Other people do have problems by the way (ME).

The CLEANEST program I've downloaded was Dave Wecker's terminal program.
It compiled without ONE warning.

Some programs coming from Commodore have been the worst offenders.
I say this, but am not ungrateful - their examples have been VERY HELPFUL.
But I get bizillions of warnings due to completely indisciminate swapping
of ints and pointers, and no extern'ing of functions before calling them.
Bad code "from the field" could have been caused by the ROM Kernel manuals,
too, which contain thousands of errors (and huge omissions!) in the code
examples.

E.g: timer device stuff uses a structure a pointer(!), and doesn't open the
timer device in the first place and then uses it (how!).

>If I can't get help from the net, this frustrating monster is going out the
>window.  I'll scrape enough money together to go buy a Sun or a microVAX.

I understand where you're coming from, but hang in there - I've "ploughed"
my way through the bugs, bad documentation, and sloppy code.

Dave Wecker's terminal program (which I'm using now) was a "breath of
spring" - try it.

All the negatives aside, the Rom Kernel manuals are FANTASTIC considering
the conditions under which they were put together, and if you can read
"between the lines".  The DOS manuals are almost hopeless for a developer.

Also, you've been SPOILED by using Vaxen and Suns - they've been around
(especially the former) for a LOT longer and have MASSIVE organizations
(DEC) behind them, whereas Commodore has basically been the manufacturer
of home computers.  Apple did a lousy job with the Mac at first and the
Amiga is lucky to have the public domain support it does (you get what
you pay for remember).

	Regards,
		Paul Higginbottom.

Disclaimer: I do not work for Commodore and my opinions are my own.