Index
> Main > choosing endian format |
| Author |
|
. well, from the previous paragraph, you can probably imagine I get a lot of those "errors".
|
revolution 19 Jul 2008, 01:59
You can't set the endian in fasm, it is always little endian. You can probably make some macros to convert the endian of your data. Are you programming for Motorola chips?
Size checking is needed so that fasm knows which instruction to assemble. If you try to disable it then you have to make a decision as to which size to assemble. e.g. how do you assemble this line "mov [var],17"? Is it a byte, word, dword or qword store? |
|||
19 Jul 2008, 01:59 |
|
|
StarKnightD 19 Jul 2008, 08:15
actually, an instruction like "mov [var], 17" already needs a size qualifier regardless of FASM size checking. the size check I'm referring to uses a register, like this:
mov eax, [data] ; data needs to be DWORD, not byte. ... data section data db '0','0' ..... I just checked and yeah, putting a size value will override the warning, however it still doesn't resolve the little endian format.. I write my code to consider the little endian format (DQWORD, loop unrolling and such), so having fasm encode each DWORD (or any other data) puts some serious bugs into my code. if fasm considered memory flat, half of the errors in my code would be gone. somebody hit me if I've answered my own question here: declare ALL memory as DB, and use the size qualifier as an override. D'OH! no, it doesn't.. how about larger data that's known prior to running, like: double_data DQ 1.623426 the format in which fasm encodes is a serious logic issue that's plaguing my code. |
|||
|
19 Jul 2008, 08:15 |
|
|
revolution 19 Jul 2008, 08:56
I think it would be easier if you simply used all your data in little endian format. You seem to be confusing yourself by trying to fight the natural endian of the CPU. I suggest you don't fight it, but rather use it as it was intended.
|
|||
|
19 Jul 2008, 08:56 |
|
|
StarKnightD 19 Jul 2008, 17:41
the point is that I'm using transfers which dump multiple bytes into cache/ram in a single instruction, I've grown accustom to little endian, I'm not fighting the natural endian of the cpu.
I want to read down a large array linearly, where each element has been declared to be larger than 1 byte, and not have to deal with fasm re-sorting the data within each block. Code: movdqa xmm0, dqword [address] this produces some seriously awkward results depending on what has been declared to be at address. |
|||
|
19 Jul 2008, 17:41 |
|
|
revolution 19 Jul 2008, 18:08
fasm won't resort any data. Perhaps I don't understand what you are trying to do. The CPU expects little endian data when it loads things from memory so fasm stores everything in little endian format.
Can you be more spcific? Maybe give an example of your problem. |
|||
|
19 Jul 2008, 18:08 |
|
|
StarKnightD 20 Jul 2008, 06:24
actually, I've tried to explain it in multiple ways. and the real issue is that I simply want the pre-runtime constants in big endian format. the cpu isn't going to roll over and die just because the data is in big endian format. it doesn't know what format it's in.
I don't have an AMD processor anymore, so I have to ask, are people who compile code with an AMD processor ultimately rendering software with bugs in it, or is fasm completely incompatible with AMD hardware? oh yeah, Quote: fasm won't resort any data. Perhaps I don't understand what you are trying to do. The CPU expects little endian data when it loads things from memory so fasm stores everything in little endian format. the first (of the 3) sentence is in conflict with the last sentence.. you said fasm isn't resorting any data in the first sentence, but you then say it's compensating for the cpu expecting little endian format: This is re-sorting the data.  |
|||
|
20 Jul 2008, 06:24 |
|
|
revolution 20 Jul 2008, 06:42
I think you misunderstand the CPUs. AMD x86 processors are also little endian. They run the same binaries as Intel CPUs. Note also that the Via, Hitachi, Cyrix and all other x86 clone CPUs are also little endian.
fasm uses the CPU to store the values, the CPU is little endian, so the values stored will be in little endian format. When you later reload them the CPU loads them in little endian and you get back what you stored. I don't think it is good to think of it as resorting the data. The CPU stores things in the format it understands. The only time this becomes important is where you are addressing sub-bytes of a larger value. Now, this where I mention in the my first post here, you want to store data in big endian format, therefore you want to fight the natural endian of the CPU. Both AMD and Intel CPUs only understand little endian format so you need to do an extra conversion after you load a big endian value in order that the CPU can properly operate on your data. To convert the endian there is xchg for 16bit values and bswap for 32bit and 64bit values. |
|||
|
20 Jul 2008, 06:42 |
|
|
baldr 29 Jul 2008, 05:13
May this snippet be of some use for you:
Code: struc dq_be [data] { local ..byte, ..dqword_be virtual at 0 dq data ..dqword_be = 0 repeat 8 load ..byte byte from %-1 ..dqword_be = (..dqword_be shl 8) or ..byte end repeat end virtual . dq ..dqword_be } It is simple: define [virtual] low-endian value  , swap it's bytes, define real low-endian (initialized with big-endian value ).
On holy wars and a plea for peace: I think, CPU doesn't bother with data's endianness, it just follows the path of it's circuitry .
But results are more meaningful when data interpreted in a proper way. Low-endian for x86, usually; on the contrary, please tell me the endianness of BSWAP instruction's data, both input and output . |
|||
|
29 Jul 2008, 05:13 |
|
< Last Thread | Next Thread > |
Forum Rules:
|