gilham@Portia.Stanford.EDU (fred gilham) (03/16/89)
The new a68k (version 2.42) that came over comp.binary.amiga
recently seems to have problems with the BSS directive. At least,
when I tried it on the output from the c compiler on fish 110
(compiled sieve.c), then linked it and tried to run it, I got "unable
to load -- not an object file" from the cli. I tried it with the old
version of a68k that I had (1.02 I think) and everything worked fine. The
problem seemed to be that the BSS directive was being screwed up somehow,
since the working file was about 8k long (though this seems wrong too! --
doesn't BSS mean that you don't have to include the actual data, just
allocate memory?) and the non-working file was much shorter. So maybe
both versions are screwing up and the old one just happens to do something
useful, though wrong?
Besides this, the new a68k is great! I mostly use it for assembly
programming, and it is much faster on the files I've tried it on.
(I also read a while back that there was something wrong with the
CHIP and FAST arguments to the section directives. Do these work now?
- I suppose I could just try them myself...)
-Fred Gilham gilham@portia.stanford.edugilham@Portia.Stanford.EDU (fred gilham) (03/21/89)
In article <918@Portia.Stanford.EDU> gilham@Portia.UUCP (me) writes: > > The new a68k (version 2.42) that came over comp.binary.amiga >recently seems to have problems with the BSS directive. The problem is not a68k. It is (I think) in the Sozobon c compiler. When I compiled the sieve.c program from fish 110 pdc/examples with zc, it produced the following code: BSS BSS XDEF _flags _flags: ds.l 0 ds.w 0 (about 4000 more ds.w 0 statements) Stupid me looked at that and wondered why a68k didn't put anything in the bss hunk and why the result of linking was a bad object module. The same person also thought he had gotten these results with pdc, which doesn't even produce a bss directive. Sorry for anyone who has wasted any time trying to troubleshoot this. -Fred Gilham