From:	"Rylan" <rylan AT intekom DOT co DOT za>
Newsgroups:	comp.os.msdos.djgpp
Subject:	as internal declarations - gfx demo
Date:	Tue, 25 Aug 1998 23:15:47 +0200
Organization:	The South African Internet Exchange
Lines:	44
Message-ID:	<6rvag9$82e$3@news2.saix.net>
Reply-To:	"Rylan" <rylan AT inbtekom DOT co DOT za>
NNTP-Posting-Host:	pc25-01-p15.saix.net
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Hi,

I recently converted a real mode graphics demo (a shadebob effect) to DJGPP
using NASM - the NASM module is simply an instruction by instruction
conversion of the real mode assembler program with adjusted adressing for
protected mode of course.

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. 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? 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"? Or the incrementation loop has to
be adjusted to add 4 bytes (dword sized data) between each access of a
supposedly byte sized table that is now running as a dword sized table?

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.

Any ideas? Please reply by mail if at all possible.

FANX!!!!

--
Spawned By Rylan
Is truth beauty or beauty truth?

- Raw text -