Comments: Authenticated sender is From: "George Foot" To: rylan AT inbtekom DOT co DOT za Date: Wed, 26 Aug 1998 02:19:39 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: as internal declarations - gfx demo Reply-to: george DOT foot AT merton DOT oxford DOT ac DOT uk CC: djgpp AT delorie DOT com Message-Id: Precedence: bulk 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