From: "Rylan" 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" NNTP-Posting-Host: pc25-01-p15.saix.net To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk 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?