Hey guys, I've wrote this little program here (without help, whoohoo!!) that checks to see if a number is even or odd.

-------------------------------

.data
mynum dd 4244335532
evennum db "This number is even", NULL
oddnum db "This number is odd", NULL

.code

start:

BT mynum, 0
JNC iseven
JMP isodd

iseven:
invoke MessageBox, NULL, addr evennum, addr evennum, MB_OK
jmp exitprog

isodd:
invoke MessageBox, NULL, addr oddnum, addr oddnum, MB_OK

exitprog:
invoke ExitProcess, NULL

end start
-------------------------------

I was reading something and read about the BT opcode. I was like, what could I use this for to learn how it works? And then I knew! Even or odd numbers. An even number in binary code always has a 0 in the 1's column. An odd number always has a 1 in the 1's column.

When I first wrote the program, I figured an odd number would look like this:

xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxx1

and that an even number would look like this:

xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxx0

So I tried in my BT command:

BT mynum, sizeof mynum

But that didn't work because my processor uses the little-endian style. So I tried BT'ing the first bit instead of the last and it worked.

My question is, how can you know what bit-style (big/little endian) the processor is using, so you know when to say:

BT mynum, 0

or:

BT mynum, sizeof mynum ?

Does it even matter? I'm quite a newbie. I'm also sort of proud of myself for thinking to check the first bit instead of the last :grin:
Posted on 2002-04-16 17:13:18 by Ronin Magus
.data

mynum dd 10111111000000001111111100000001b; 4244335532
evennum db "This number is even", NULL
oddnum db "This number is odd", NULL

.code

start:

BT mynum, 23
JNC iseven
JMP isodd

iseven:
invoke MessageBox, NULL, addr evennum, addr evennum, MB_OK
jmp exitprog

isodd:
invoke MessageBox, NULL, addr oddnum, addr oddnum, MB_OK

exitprog:
invoke ExitProcess, NULL

==============================
Hey, Ronin Magus

I'd never used "BT" but i found it

Usage: BT dest,src
Modifies flags: CF
The destination bit indexed by the source value is copied into the Carry Flag.

as this, BT opcode tests "indexed" BIT.

so, you can use this like below

BT mynum, 0
or
BT mynum, 1
.
.
.
BT mynum, 30
or
BT mynum, 31
=============================================

and.. you said
===
My question is, how can you know what bit-style (big/little endian) the processor is using, so you know when to say:
===

As I know, some processor uses Big-endian style, but Intel family
uses little-endian style.
Posted on 2002-04-16 20:00:14 by muzidowa
Ronin Magus: Motorola is little endian and Intel is big endian... don't worry about that kind of things since the code wouldn't work on other types of processors.
Posted on 2002-04-16 20:14:05 by tmb
well, here is a test (outlined):

have a known value, like:
mynum dd 80000000h (top bit is set)
or:
mynum dd 01h (bottom bit is set)
as a control value.
then test to see where the bit appears. then execute your code accordingly.
Posted on 2002-04-16 21:21:29 by jademtech
Well I was asking because I know Intel is little-endian but isn't AMD big-endian? Since those are the 2 most likely to run this code I need to know be able to figure out which it is.

Jade, that's probably the best solution. That's what I was thinking of doing but I wanted to know if there was a better way
Posted on 2002-04-16 21:32:12 by Ronin Magus
My mistake. I did a little googling and it seems both intel and amd are little-endian, so the "BT mynum, 0" should pull the same results on both of them.
Posted on 2002-04-16 21:48:43 by Ronin Magus
I use the BT op-codes in most of my programs as flag controls.
My_flags dd 0
err_flag equ <My_flags,00> ;can have 32 flags here
red_flag equ <My_flags,01>

.code
btc red_flag
jnc red_not_set

My first post, see what happens..
John:confused:
Posted on 2002-04-17 04:28:49 by John McLaughlin

Well I was asking because I know Intel is little-endian but isn't AMD big-endian? Since those are the 2 most likely to run this code I need to know be able to figure out which it is.


You don't have to worry about this if you're programming for windows. Windows has been written for intel x86 (except for the versions for the alpha) so if AMD's processors wouldn't have the same architecture as intel's, you couldn't even run windows on it.
The only difference between both processors is their additional sets of instructions (SSE, 3DNow!), some of which they have in common (MMX).

Thomas
Posted on 2002-04-17 05:08:24 by Thomas
I think its fair to say, if you program in assembly you'll never need to test the endian-ness of the processor!

If you need to test in C (as it is portable if written correctly), then you can do something like this



int x = 1;
int* ptr_x = &x;

if (char*(ptr_x) == 1)
// Little endian


The endian-ness of a processor will affect the way data is presented in memory, in registers it is all transparent as all necessary swapping will be done. Therefore by writing a value (bigger than 1 byte) out, then reading back the first byte (in memory) will determine the endian-ness of the processor.

But as I said, assembly is so non-portable you'll never need to test the endian-ness at runtime, and chances are you could find a compiler flag to find the endian-ness for you anyway and conditionally compile byte swapping when needed (which is what I have to do on my Sun/PC program).

Mirno

--- Please note the above code is off the top of my head, and my not be entirely correct, but the idea behind it is sound ---
Posted on 2002-04-17 05:39:42 by Mirno

Ronin Magus: Motorola is little endian and Intel is big endian... don't worry about that kind of things since the code wouldn't work on other types of processors.
Misinformation.

This is how things really are:

Motorola 680x0 = big endian
Motorola PowerPC = big endian or little endian (selectable)
Intel IA32 = little endian
AMD IA32 clones = can't be anything else than little endian, no?
Posted on 2002-04-17 06:46:29 by Maverick
I might be wrong about this, but... I don't really think the endianness
should matter when testing bits. Binary is right-to-left, least significant
bit at the rightmost position. So, bit0=1, bit1=2, bit2=4 (and so on).
Endianness affects the byteorder of multi-byte quantities (16 words,
32bit dwords, and so on).

And as other people have said, how would you expect AMD processors
to be binary compatible with Intel processors if they had different
endianness? ;)
Posted on 2002-04-17 07:00:06 by f0dder

Misinformation.

This is how things really are:

Motorola 680x0 = big endian
Motorola PowerPC = big endian or little endian (selectable)
Intel IA32 = little endian
AMD IA32 clones = can't be anything else than little endian, no?


Thanks for the right information... my experience with Motorola is limited to the Right Machine meaning of course Atari ST. :rolleyes:

What's the good part of little endianess? I thought it was very handy to point to the byte, word or dword part of the number with the same address?
Posted on 2002-04-17 07:12:41 by tmb

What's the good part of little endianess? I thought it was very handy to point to the byte, word or dword part of the number with the same address?

That's exactly what's good about little endianness. The only advantage
of big endian I can see is that values are easier to read if you do
a memory dump - I do think ease of code is a bit more important
than that.
Posted on 2002-04-17 07:15:57 by f0dder
f0dder:

Incidentally in our western languages we're used to type/read from left to right.
In my tools (my own debugger, etc..) I dump memory the other way round instead:


FEDCBA98 76543210 address

etc..

i.e. from right to left instead of the usual left to right.

this way little endian behaves perfectly.. in all senses.

I find it also very readable.. since the most significant part should always be to the left.
Posted on 2002-04-17 07:53:02 by Maverick
For those interested.. you can "turn" a little-endian CPU to a big-endian (and vice-versa) in practice, doing just this:

for 32bits:


MOV EAX,[mem]
BSWAP EAX


for 16bits:


MOV AX,[mem]
ROL AX,8


Then it's perfectly equivalent as you had the other endianess type of CPU.
Posted on 2002-04-17 08:00:02 by Maverick