flat assembler
Message board for the users of flat assembler.

Index > Main > choosing endian format

Author
Thread Post new topic Reply to topic
StarKnightD



Joined: 04 Jul 2007
Posts: 38
StarKnightD
is there any way to choose the endian format which FASM (not intel) builds code to? when declaring data that is larger than a byte, but addressing elements which are smaller (say, 1 byte) it introduces serious logic issues.

also, by extension, is there an option to turn off size checking? this is nice and all, but I don't need it Cool . well, from the previous paragraph, you can probably imagine I get a lot of those "errors".

Thanks,
starknightd


Last edited by StarKnightD on 20 Jul 2008, 04:55; edited 1 time in total
Post 18 Jul 2008, 18:55
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
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?
Post 19 Jul 2008, 01:59
View user's profile Send private message Visit poster's website Reply with quote
StarKnightD



Joined: 04 Jul 2007
Posts: 38
StarKnightD
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.
Post 19 Jul 2008, 08:15
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
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.
Post 19 Jul 2008, 08:56
View user's profile Send private message Visit poster's website Reply with quote
StarKnightD



Joined: 04 Jul 2007
Posts: 38
StarKnightD
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.
Post 19 Jul 2008, 17:41
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
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.
Post 19 Jul 2008, 18:08
View user's profile Send private message Visit poster's website Reply with quote
StarKnightD



Joined: 04 Jul 2007
Posts: 38
StarKnightD
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. Evil or Very Mad
Post 20 Jul 2008, 06:24
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17270
Location: In your JS exploiting you and your system
revolution
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.
Post 20 Jul 2008, 06:42
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
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 Wink, swap it's bytes, define real low-endian (initialized with big-endian value Wink).

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 Wink.
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 Wink.
Post 29 Jul 2008, 05:13
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.