Mail Archives: djgpp/1998/08/25/21:21:29
On 25 Aug 98 at 23:15, Rylan wrote:
> Then, I felt interested in doing an AT&T format conversion.... BOOM! It does
> not work at all - by that I mean that I have VERY carefully checked each
> line of code, and I am sure that each one corresponds correctly to the
> original NASM version. The AT&T version runs 100% fine and compiles
> perfectly, the only thing is it looks wrong! I then had GCC output the .S
> file for the effect.
If you're converting code you wrote in NASM then I think it would be
better to write it in .S files directly, rather than inlining it in
C source files. It would probably be more efficient, and less
error-prone. If you want a bit more information on doing this, see:
http://users.ox.ac.uk/~mert0407/asmfuncs.txt
Presumably you already know how to do most of this because you're
already doing it in the NASM code.
> Now, the NASM module had two include files that
> included byte and word sized arrays of data for the graphics effect (sine
> and cosine tables) I translated these to C include files, using "unsigned
> int" for "dw" and "unsigned char" for "db" like it was used for NASM.
> However, in .S file just mentioned, GCC has pre-assembler-processed these db
> and dw "equivalents" (that is "unsigned int" and "unsigned char") into just
> AS format .long declarations. .long?
`.long' means "write this 32-bit value into the next four bytes, and
increase the current position by four". ".long 0x12345678" means the
same thing as ".byte 0x78, 0x56, 0x34, 0x12". I suspect that gcc is
combining the values in your byte array into groups of 4 before
writing out a `.long' statement.
> I thus suspect that the effect is not
> working right because some of the variables for the cosine and sine tables
> are not in the correct size - i. e. what has to be stored in a byte for it
> to actually represent the correct value is now stored in a double word -
> .long = long integer? And that this is the reason the effect is snarfing
> off? A "movb [20]sintab,%ah" (never mind if this is not valid at&t, only for
> illustration)thus pulls the wrong stuff out of the array that the assembly
> pre-processor considers a dword ".long"?
The amount added on by `20' cannot depend upon whether `.long' or
`.byte' (or anything else) was used to create the space for the array
-- it's really irrelevant how the array was created. At that point
in the code, the processor just knows to add an offset on to a
pointer, dereference and store the byte there in AH. It has no idea
what assembler psuedomnemonic was used to allocate the array.
> Is this possible? How can I force AS to declare ".byte" and ".word" (to use
> direct analogy to ".long"?) Can this be the error? The NASM version runs
> fine, so it MUST work under DJPGG - only the AT&T one includes the data for
> the sine and cosine as .H - and then in the resultant .S is uses them as
> .long.
The solution is to write the tables yourself, in .S format. Just
write:
.global _table_name
_table_name:
.byte value, value, value, value, ...
.byte value, value, ...
...
If it's not going to be accessed by other files you can drop the
`.global' line.
I think your real problem isn't this though. It's probably a mistake
somewhere in the interaction between your inline assembler and the
functions containing it, possibly involving gcc's optimiser (did you
list the clobbered registers properly?).
In any case, when you're writing whole functions in assembly language
it's much better to write in in .S format because then you don't have
to worry about telling what you've clobbered (so long as you remember
the calling conventions).
--
george DOT foot AT merton DOT oxford DOT ac DOT uk
- Raw text -