flat assembler
Message board for the users of flat assembler.

Index > Heap > Endianness?

Goto page Previous  1, 2, 3, 4  Next
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17260
Location: In your JS exploiting you and your system
revolution
Yes, network byte order is big-endian. But that has nothing to do with the size of a byte or wastage of memory.
Post 25 Dec 2009, 15:46
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
kohlrak wrote:
Wrong... If you declare "dw AB", it's stored the same as "db B, A." Therefore...
dw AB doesn't compile. Did you mean dw 'AB'?

and you know, that's how FASM works to appease to those like you. It's not the CPU or little-endian telling it to be that way, but oh well.

kohlrak wrote:
In both cases, the result is wrong if 'AB' represents a non-string. Because in actual ax register is like this internally.

Code:
|AL|AH|    
What? How do you know how it is internally, did you open up your CPU? It can be however it wants internally, there's no address assigned to it. It is arranged optimally for the specific case, if it was rotated 180 degrees, where do you start from? There is no "left" or "right", be more realistic. There are just two points to start from the 'line', if the bit sequence is even on a line, but that's not necessarily.


@All Big-Endian fans:
Why are you so stubborn to see this from a logical viewpoint?

Here let me reformulate, hope you'll see it:

Little Endian: low byte in register -> low address in memory
Bid Endian: low byte in register -> high address in memory


Please tell me, which one is backwards... Use reason as argument please, not a stupid mirror with no explanation.


Stop thinking of cultural norm and apply some logic to it and you'll see. By the way the 'order' of the bits is unspecified. Were it not for shifting, you would have had no orientation sense. Unfortunately the Intel guys made shifting backwards (as in big endian) and now it causes confusion.


You're reading it backwards.

You start from low memory but expect the high byte first. This is backwards, if the program in question displayed highest memory first then little-endian would "make sense" to those ignorant of logic, even though it makes sense always.

So next time read from right to left or modify the program to display highest memory first and going lower to the right.

Either that, or (the right thing) simply expect the low byte first. You count from low address to high address so count from low byte to high byte also, otherwise you have it backwards. End of story.

_________________
Previously known as The_Grey_Beast
Post 25 Dec 2009, 17:53
View user's profile Send private message Reply with quote
Artlav



Joined: 23 Dec 2004
Posts: 188
Location: Moscow, Russia
Artlav
Ouch, i didn't expect to spawn a holywar, sorry.

What i realized about the endianness in Intel after thinking about it, is that the bits are actually also left-to-right - bits are counted like the bytes, so adding to memory being one big number. But, the NAMING in all books and shift notation is actually backwards for some reason, maybe historical one - shift left defined as *2, right - /2.

And here is where i got confused - representation and facts didn't add up.

It's curious, how you can use something for a decade, without being able to tell in words what it actually is.
Post 25 Dec 2009, 18:51
View user's profile Send private message Visit poster's website Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
dw AB doesn't compile. Did you mean dw 'AB'?


No, A and B represent 1 byte (per letter) hex values I assume from your example. If not, it's a string, and an invalid argment, as it is, by far, an impractical situation (strings are not ints for those of you who don't understand).

Quote:
and you know, that's how FASM works to appease to those like you. It's not the CPU or little-endian telling it to be that way, but oh well.


Then go use another assembler. Razz

Quote:
What? How do you know how it is internally, did you open up your CPU? It can be however it wants internally, there's no address assigned to it. It is arranged optimally for the specific case, if it was rotated 180 degrees, where do you start from? There is no "left" or "right", be more realistic. There are just two points to start from the 'line', if the bit sequence is even on a line, but that's not necessarily.


Have you bothered to ever code things that are subject to big-endian and little-endian conflicts? I have, fortunately, which is why this is such an easy topic for me. Go ahead, make a program that prints out this number as a hex-decimal dword "db 0xFE, 0xDC, 0xBA, 0x98". I bet you that if you then print out AL, you will find that AL holds 0x98! Low and behold, if you do the same thing with "dd 0xFEDCBA98," it'll print out FE in AL! WOW! And i didn't even have to open my CPU to do it!

Quote:
Why are you so stubborn to see this from a logical viewpoint?


Is it us who do not see?

Quote:
Use reason as argument please, not a stupid mirror with no explanation.


Mirrors are good to remind you of your own failed logic.

Quote:
Stop thinking of cultural norm and apply some logic to it and you'll see.


Leaving cultural norm? Then base-x is perfectly fine!

Anyway, i won't bother to respond to the rest until you write that program and look at the outputs.

Artlav wrote:
Ouch, i didn't expect to spawn a holywar, sorry.

What i realized about the endianness in Intel after thinking about it, is that the bits are actually also left-to-right - bits are counted like the bytes, so adding to memory being one big number. But, the NAMING in all books and shift notation is actually backwards for some reason, maybe historical one - shift left defined as *2, right - /2.

And here is where i got confused - representation and facts didn't add up.

It's curious, how you can use something for a decade, without being able to tell in words what it actually is.


They did say what it is, "confusing." It's not that hard, it takes a little practice and a few example programs. The real trick is, the bits internally in a byte go from right to left, like how we do numbers in left to right languages (highest valued digit to the left, lowest to the right). Then the bytes themselves are swapped around. So a dword kinda looks like this (where numbers are bit indexes and ";" means "end of byte"):

7 6 5 4 3 2 1 0; 15 14 13 12 11 10 9 8; 23 22 21 20 19 18 17 16; 31 30 29 28 27 26 25 24;
Post 26 Dec 2009, 05:57
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 692
Location: Adelaide
sinsi
You are throwing around 'AL' but how are big-endian registers named? Surely they don't use EAX et al.

>If I am not badly mistaken, IBM introduced the System 360 in the mid 1960's, i.e. 45 years ago, not 30.
I was referring to the date of the article (April 1st no less...)
Post 26 Dec 2009, 06:08
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
sinsi wrote:
You are throwing around 'AL' but how are big-endian registers named? Surely they don't use EAX et al.

>If I am not badly mistaken, IBM introduced the System 360 in the mid 1960's, i.e. 45 years ago, not 30.
I was referring to the date of the article (April 1st no less...)


Actually, i've looked at a few other CPU families (not an expert so i'm not sure about my next statement), and the x86 CPU is the only CPU that i've seen that gives non-numerical names to the registers. Other systems (i assume they're also fixed width or something) use just r#. EAX, EBX, ECX, and EDX should be r1, r2, r3, and r4 respectively. Not sure about the order for the other registers.
Post 26 Dec 2009, 06:25
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17260
Location: In your JS exploiting you and your system
revolution
By Intel encoding the order is r0=ax, r1=cx, r2=dx, r3=bx, r4=sp, r5=bp, r6=si, r7=di.

kohlrak: Why did you start your numbering at 1?
Post 26 Dec 2009, 07:02
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17260
Location: In your JS exploiting you and your system
revolution
"big-endian in the real world."

As you know, most countries cultural practice is to use BE in everyday life for numbers. But is it efficient?

In English we also pronounce numbers in BE format. One thousand four hundred seventy six. Biggest to smallest. But when we see the number written, 1476, and try to say it, we have to do two extra things before we can start to say the number. 1) We have to scan to the end of the number and count the digits to get the full magnitude, and 2) we have to go back to the beginning of the number to then begin reading off the digits in the proper scale.

In some non-English languages the number pronunciation is LE. Six and seventy and four hundred and one thousand. But when we see the number written, 1476, and try to say it we have to do one extra thing before we can start to say the number and one extra thing after we say the number. 1) We have to scan to then end of the number to get to the first digit to pronounce, and 2) once we have said the number we have to go back to the end of the number to continue reading more text.

Now my example uses a small 4 digit number and I am sure all reading this will think this is trivial to do. And it is, because we have learned to do this from an early age. However consider what happens with a longer number, say 65859029532. Now think about how you saw that number. Could you start straight away and say six ... (something)? I expect not. You have to count the digits before being able to know the magnitude of the 6 position. It slowed you down.

Even in non-English language with LE speaking customs you have to do mental backtracking and then forward again to be able to say the number in LE form.

But consider if instead a society were to have an LE system for both written and spoken numbers. You would not need to scan ahead to discover magnitudes before starting to say numbers. And you would never have to backtrack across things you have already seen to continue reading.
Post 26 Dec 2009, 09:47
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
kohlrak wrote:
No, A and B represent 1 byte (per letter) hex values I assume from your example. If not, it's a string, and an invalid argment, as it is, by far, an impractical situation (strings are not ints for those of you who don't understand).
What makes a string different, scientifically speaking, than an int? All I see are a sequence of 1s and 0s, or a sequence of bytes...

can you think logically, concretely, without bias?

And what do you mean by A B representing 1 byte per letter? db 'A', 'B'? Sorry, that's not 'dw', it's a sequence of two dbs. But even in that case, little-endian is more logical.

Let's see, what you are essentially doing with db 'A', 'B' or db 'AB' is putting 'A' at the current address and 'B' at current address+1. That's the scientifical definition.

So uhm... in little endian if you load up a word at current address you will get at the lowest byte 'A' and highest byte 'B'.

After all 'A' is in the lowest address and 'B' is the highest, so I think this is the logical endianness.

Big Endian, on the other hand, for some stupid reason, puts up 'A' in the HIGHEST byte (i.e lowest address->highest byte). This is backwards. It's like WRITING (with db) from left to right, but reading from right to left. this is big endian for you.

kohlrak wrote:
Then go use another assembler. Razz
Why? It's a feature I don't use anyway -- and how is that any sort of proof for efficiency? I don't see any logical or scientific arguments from you, all I see is "it's how I think it should be" or "that's how that is, it means it's correct/more efficient. No analyzing needed!" or "it's how MY program displays it!". That's like the opposite of scientific analysis. You know, you have to analyze why the tools work the way they do before saying "the tools says so, it must be true!", especially with subjective notions as to how to display memory addresses!

kohlrak wrote:
Have you bothered to ever code things that are subject to big-endian and little-endian conflicts? I have, fortunately, which is why this is such an easy topic for me. Go ahead, make a program that prints out this number as a hex-decimal dword "db 0xFE, 0xDC, 0xBA, 0x98". I bet you that if you then print out AL, you will find that AL holds 0x98! Low and behold, if you do the same thing with "dd 0xFEDCBA98," it'll print out FE in AL! WOW! And i didn't even have to open my CPU to do it!
You completely missed the point. First of all it's big endian that causes the conflicts, not little endian. But that was just a remark for a totally off the point.

How do you know the "order" of the bits? Please use some rational analysis and think: what gives you the 'direction' of those bits, physical direction and not bias?

Obviously you CANNOT say that a given PROGRAM, like a binary editor or hex editor, shows it that way: it's just the program's convention, I can make a program displaying it in reverse, why not? This does not say anything about the physical order of the bits, it's bias.

So where do you get the order/sense from? Left/Right? Where?

the only one where you get it is from shifting and rotate instructions. Those are the only instructions which have a notion of sense (from direction). However I have already said, those come from big endian, and Intel adopted them.

If Intel were to choose little-endian shifting it would be the perfect/best approach, unfortunately they didn't Sad

Furthermore the shifting/rotating instructions only tell you an abstract sense -- in reality, they aren't even menomics, just code of instructions -- inside the CPU, the flip-flops for the registers could be arranged in any way, possibly more optimally than a line!

kohlrak wrote:
Mirrors are good to remind you of your own failed logic.
Except that the mirrors make no sense whatsoever. What you do is essentially this:

Me: Blue is the color of the daytime ocean, that's why [...].
You: Purple is the color of the daytime ocean, that's why [...].

(the colors are just an analogy, randomly, don't mind them Razz).

You see, I make a statement, but statements with arguments can't be mirrored, unlike yours. You can't mirror my posts AND make sense because the arguments would be messed up, see above why. That's why you don't make sense with it. Mirroring only works on posts with no arguments. Claims, if you will. Wink

I asked for an explanation. Can you provide one, or are you so biased that the only one you can is "I think/say it's right, no analysis required." Make a comparative analysis based on MEASURABLE arguments, like me.

kohlrak wrote:
Leaving cultural norm? Then base-x is perfectly fine!
Sure, if you can prove or demonstrate why 'x' is a good and efficient base, I'm all for it. I mean, that's why we chose base-2 in the first place!



Ok now I feel like you take everything too abstractly. First of all there is no left or right, it's only memory addresses. The program, depending on how it's coded, displays the addresses in a certain way. the addresses themselves have no notion of "left" or "right" or "up" or "down", they're just a sequence of consecutive numbers.

Now with that out of the way, little endian is simply the following representation of how addresses get loaded into registers:

low address->low byte, high address->high byte

Does that seem backwards to you? Does that seem illogical to you? Does that seem biased to you?

So what was your point?

_________________
Previously known as The_Grey_Beast
Post 26 Dec 2009, 17:53
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
revolution wrote:
By Intel encoding the order is r0=ax, r1=cx, r2=dx, r3=bx, r4=sp, r5=bp, r6=si, r7=di.

kohlrak: Why did you start your numbering at 1?


Cause I saw rax as r1 somewhere else before, actually. I think it was a fasm forum member's website, so i can't vouch for accuracy. Also, i don't think they had an r0 on the other systems i looked at (not that i looked really hard, just examined random bits of source code).

Quote:

"big-endian in the real world."

As you know, most countries cultural practice is to use BE in everyday life for numbers. But is it efficient?

In English we also pronounce numbers in BE format. One thousand four hundred seventy six. Biggest to smallest. But when we see the number written, 1476, and try to say it, we have to do two extra things before we can start to say the number. 1) We have to scan to the end of the number and count the digits to get the full magnitude, and 2) we have to go back to the beginning of the number to then begin reading off the digits in the proper scale.

In some non-English languages the number pronunciation is LE. Six and seventy and four hundred and one thousand. But when we see the number written, 1476, and try to say it we have to do one extra thing before we can start to say the number and one extra thing after we say the number. 1) We have to scan to then end of the number to get to the first digit to pronounce, and 2) once we have said the number we have to go back to the end of the number to continue reading more text.

Now my example uses a small 4 digit number and I am sure all reading this will think this is trivial to do. And it is, because we have learned to do this from an early age. However consider what happens with a longer number, say 65859029532. Now think about how you saw that number. Could you start straight away and say six ... (something)? I expect not. You have to count the digits before being able to know the magnitude of the 6 position. It slowed you down.

Even in non-English language with LE speaking customs you have to do mental backtracking and then forward again to be able to say the number in LE form.

But consider if instead a society were to have an LE system for both written and spoken numbers. You would not need to scan ahead to discover magnitudes before starting to say numbers. And you would never have to backtrack across things you have already seen to continue reading.


I can see potential number-related puns in the making for a language that writes and speaks numbers in LE... But anyway... I don't think natural languages were ment for reading really long numbers (say a 9 digit with a non-zero digit and see how long it takes you to be willing to say it again). However, if you throw away potential for puns (if the language was carefully constructed it would never be a problem, however puns existing at all shows they aren't Laughing) it would surely be more efficient. However, going into natural language, we start to delve into other departments. For example, how efficient is the rest of the language? For example, if you're reading japanese or chinese, they're very efficient. For firefox, my one toolbar with all the links (smart links is it called?) managed to hold only less than 10. Right now, after converting the english to Japanese, I have 19 buttons up there. However, if you were to speak japanese, you'd surely tire your mouth out as fast as you would speaking english. Anyway, that was off topic. For spoken languages where words like "thousand" and such are used (informally spoken, many numbers are said by digits or digits in brackets, and seldom properly with million, thousand, hundred, and the like: sit in a math class and see how they pronounce numbers following a decimal point) little endian is more efficient for speaking.

Quote:
What makes a string different, scientifically speaking, than an int? All I see are a sequence of 1s and 0s, or a sequence of bytes...


They're not ment to be dealt with as numbers? hm... seems valid to me...

Quote:
can you think logically, concretely, without bias?


If you dare say my logic is biased, then this argument is pointless because everything comes with a degree of bias, shown pretty well to you in previous posts.

Quote:
And what do you mean by A B representing 1 byte per letter? db 'A', 'B'? Sorry, that's not 'dw', it's a sequence of two dbs. But even in that case, little-endian is more logical.


Are you really that stupid?

Quote:
Let's see, what you are essentially doing with db 'A', 'B' or db 'AB' is putting 'A' at the current address and 'B' at current address+1. That's the scientifical definition.


Scientifical? As if computers terms are accepted in sciences.

Quote:
So uhm... in little endian if you load up a word at current address you will get at the lowest byte 'A' and highest byte 'B'. After all 'A' is in the lowest address and 'B' is the highest, so I think this is the logical endianness.


BIAS! Laughing If strings went backwords (sometimes i think that'd help a bit), you wouldn't have that problem.

Quote:
Big Endian, on the other hand, for some stupid reason, puts up 'A' in the HIGHEST byte (i.e lowest address->highest byte). This is backwards. It's like WRITING (with db) from left to right, but reading from right to left. this is big endian for you.


Some stupid reason? Seldom does big-endian do it. Sometimes i wish it would though. Anyway, it would ever do this to make things easier. And surely it could.

Quote:
Why? It's a feature I don't use anyway -- and how is that any sort of proof for efficiency? I don't see any logical or scientific arguments from you, all I see is "it's how I think it should be" or "that's how that is, it means it's correct/more efficient. No analyzing needed!" or "it's how MY program displays it!". That's like the opposite of scientific analysis. You know, you have to analyze why the tools work the way they do before saying "the tools says so, it must be true!", especially with subjective notions as to how to display memory addresses!


Well no, i'm not saying it's proof of concept (certainly is evidence though, lest you be more experienced and knowledgable than Thomasz and friends). You're bashing the assembler now. If you'd rather have a "more efficient" assembler, go use it instead. Razz

Quote:
You completely missed the point. First of all it's big endian that causes the conflicts, not little endian. But that was just a remark for a totally off the point.


How was that unrelated?

Quote:
How do you know the "order" of the bits? Please use some rational analysis and think: what gives you the 'direction' of those bits, physical direction and not bias?


See a few posts back. Me and other users don't feel like typing it all again.

Quote:
Obviously you CANNOT say that a given PROGRAM, like a binary editor or hex editor, shows it that way: it's just the program's convention, I can make a program displaying it in reverse, why not? This does not say anything about the physical order of the bits, it's bias.


I could say the same thing about whether or not the machine has registers at all! Fasm assumes they exist and the program magically pops out! But it's biased to say they exist...

Quote:
the only one where you get it is from shifting and rotate instructions. Those are the only instructions which have a notion of sense (from direction). However I have already said, those come from big endian, and Intel adopted them.


So, i guess your excuse for everything now will be, "it came from big endian and intel adopted them."

Quote:
If Intel were to choose little-endian shifting it would be the perfect/best approach, unfortunately they didn't Sad


Ah, so multiplication and dividing via shifting isn't efficient at all. Glad you told me. I didn't know there were so many more algorithms where broken shifting worked more efficiently.

Quote:

Furthermore the shifting/rotating instructions only tell you an abstract sense -- in reality, they aren't even menomics, just code of instructions -- inside the CPU, the flip-flops for the registers could be arranged in any way, possibly more optimally than a line!


Wow! This is new! I never heard of this! So no wonder why i can't even view my program in a hex editor! So that's why i need an assembler to make my program run! Wow, that's so cool!

Quote:
Except that the mirrors make no sense whatsoever. What you do is essentially this:

Me: Blue is the color of the daytime ocean, that's why [...].
You: Purple is the color of the daytime ocean, that's why [...].

(the colors are just an analogy, randomly, don't mind them Razz).


If you look at the statements, they're no more or less valid than yours, simply because of what another user said, it's pretty much like left-handedness vs right-handedness. I disagree for 2 reasons, but aside from those, it's true.

Quote:
You see, I make a statement, but statements with arguments can't be mirrored, unlike yours. You can't mirror my posts AND make sense because the arguments would be messed up, see above why. That's why you don't make sense with it. Mirroring only works on posts with no arguments. Claims, if you will.


Ah, now you understand what i was getting at! You were making "arguments," but alas they were only unfounded claims, as usual.

Quote:
I asked for an explanation. Can you provide one, or are you so biased that the only one you can is "I think/say it's right, no analysis required." Make a comparative analysis based on MEASURABLE arguments, like me.


What arguments?

Quote:
Sure, if you can prove or demonstrate why 'x' is a good and efficient base, I'm all for it. I mean, that's why we chose base-2 in the first place!


X can support more values in less digits. Throw away the fact that no-one can read it, but it's more efficient digit wise. Razz I guess everyone'll have to get over their cultural bais and get used to using X based numbers. (This sounds even more rediculous if you have a base 1024 number system.)

Quote:
Ok now I feel like you take everything too abstractly. First of all there is no left or right, it's only memory addresses. The program, depending on how it's coded, displays the addresses in a certain way. the addresses themselves have no notion of "left" or "right" or "up" or "down", they're just a sequence of consecutive numbers.


Not just memory addresses. And if you continue ignoring what i'm saying lest you can ignorantly respond to it as before, this argument will just end with you spilling more junk to forum members who aren't going to bother reading your crap.

Quote:
Does that seem backwards to you? Does that seem illogical to you? Does that seem biased to you?


No, yes/no, yes.

Quote:
So what was your point?


After reading this bullshit, i don't even remember anymore.
Post 27 Dec 2009, 04:46
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2911
Location: [RSP+8*5]
bitRAKE
In a language we can all understand:
Code:
lea edi,[buff]
xor eax,eax
mov ecx,buff.bits
@@: btc [edi],eax
    inc eax
    loop @B

int3

buff.bits = 71
buff rd (buff.bits + 31) shr 5    
What is happening in reality, people? Not in the CPU. Not in your head. It is happening in memory:

[buff] bits are complemented in ascending order.

Of course, it might be convienent to imagine the bytes in a particular order (logically? Razz) or understand the memory access granularity (DWORD), but those things do not change what the code is doing.

We have already established that multi-byte operations on x86 are natively LE. Without further complexity, the native bit order is 01234567 for the BT* instructions - also LE.

Yet, shift/rotate operations imply BE bit ordering!

Were they named incorrectly?

_________________
¯\(°_o)/¯ unlicense.org
Post 27 Dec 2009, 07:50
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
kohlrak wrote:
They're not ment to be dealt with as numbers? hm... seems valid to me...
??? Explain. everything is numbers AFAIK.

kohlrak wrote:
If you dare say my logic is biased, then this argument is pointless because everything comes with a degree of bias, shown pretty well to you in previous posts.
No actually you've never provided one single argument apart from "it's how I read numbers, biggest digit first, but I want it in lowest address first!". Give me one comparative measurable argument please.

kohlrak wrote:
Are you really that stupid?
Is that all you've got as an argument for big endian? Usually it's trolls who go with personal insults, you know. Rolling Eyes

You know calling me stupid won't change the fact that all your arguments are loose, non-concrete, and unmeasurable. "dw AB" doesn't compile, unless AB is defined as a variable. If you say 'A' is at the lowest address and 'B' is at the highest, then "dw 'AB'" or "db 'AB'" represents that. If you say 'A' is at the high address and 'B' at the lowest, then db 'BA' represents that.

kohlrak wrote:
Scientifical? As if computers terms are accepted in sciences.
You are hopeless. Why am I bothering I feel like talking to a peasant. Rolling Eyes

I gave a robust definition of what is happening, plain and simple. I suppose you haven't heard of computer science either.

kohlrak wrote:
BIAS! Laughing If strings went backwords (sometimes i think that'd help a bit), you wouldn't have that problem.
Here we go again.
What the fuck do you mean by STRING RUNS BACKWARDS????

Is it that it's stored starting at the highest address? Example: you count the string length, and put the start at "address+length" and then put it but decreasing in address everytime?

What the hell is the point of that -- I don't see it. The same fucking endianness rules apply.

GIVE ME A FUCKING ROBUST MEASURABLE ANSWER AND DROP THE CHILDISH PERSONAL INSULTS.

kohlrak wrote:
Some stupid reason? Seldom does big-endian do it. Sometimes i wish it would though. Anyway, it would ever do this to make things easier. And surely it could.
I have no idea what you are talking about, yet again, you're not making any measurable sense.

Do you know what a memory address is? It's just a number. The thing is the CONVENTION as to how you use it: lowest address->highest address, is that how you count, or highest-lowest?

It doesn't matter really, the bias isn't even there. The "backwards" notion of big endian comes from the fact that lowest byte corresponds to highest address. This is backwards because on the left side of the "equation" we have "lowest" and on the right "highest".

lowest=highest
highest=lowest

That's backwards instead of straight:

lowest=lowest
highest=highest

That's all there fucking is to memory: addresses. There's no left, there's no right, there's no fucking direction, it is solely defined by addresses -- it's YOU who makes up a direction out of it, or the program you use.

I have just a question for you. Do you have any idea what information theory is about? Have you studied any THEORY so you can easily grasp why this is so?

I'm talking about what constitutes full information defining an entity, not the computer science per se -- in this case entity would be memory, and 'information' to define it would be its addresses.

kohlrak wrote:
Well no, i'm not saying it's proof of concept (certainly is evidence though, lest you be more experienced and knowledgable than Thomasz and friends). You're bashing the assembler now. If you'd rather have a "more efficient" assembler, go use it instead. Razz
You are completely hopeless, I'm amazed (shocked) how you even drew such a unrelated conclusion.

Now I feel again like talking to a peasant.

But I'm pretty sure you think that infrared looks like green -- right? That's what the night goggles display it as, surely that is proof that the infrared color is green!

Right?

Of course, Borsuc is bashing the night goggles themselves that they display it green! The color green is an innate information of infrared, it's not just the tool makers who decided it arbitrarily. No sir, it's how ACTUAL infrared looks like! Rolling Eyes

And yeah, oh, they chose green for a reason, not really arbitrarily. It may be BIAS, but it is a BIAS backed up by scientific analysis. In this case, the human eye is most sensitive to green. It has nothing whatsoever to do with the "innate" color of infrared. Infrared is just AMPLITUDE (with a specific frequency) and they convert that AMPLITUDE, which in information theory is NUMBERS, like ANYTHING ELSE, and display that with this "convention":

highest number->highest green intensity
lowest number->lowest green intensity

cool eh? Now, according to big endian theory, we should store it like this:

highest number->lowest green intensity
lowest number->highest green intensity

so a infrared-absorbing object would be green, while an object emitting/reflecting infrared light would be black.

Which one is backwards?

I'm still waiting for you to back up your big endian love for once with AT LEAST one argument apart from "I like it more". You know, a measurable argument. Something that can be COMPARED analytically.

kohlrak wrote:
How was that unrelated?
The conflict between big endian and little endian is off the point. Of course there's also the "conflict" between binary and decimal, and why we need conversions.

Does that mean computers should use decimal?

How is that an argument? Who cares about conflicts? If all the world used binary and little endian there would be no conflicts anymore. So it's big endian, from this perspective, and decimal, who cause conflicts. Razz

kohlrak wrote:
See a few posts back. Me and other users don't feel like typing it all again.
That was a rhetorical question, I answered it later. If you stopped quoting out of context every paragraph you would have seen it.

Answer: shifting are the only instructions who give you a sense of direction. And yes, they're backwards Sad

kohlrak wrote:
I could say the same thing about whether or not the machine has registers at all! Fasm assumes they exist and the program magically pops out! But it's biased to say they exist...
???

I don't see how that is any way related to what I just said.

I said that the "left" and "right" display of memory, column hex and such, are up to the program to decide. ALL what the program is fed as input information (information theory again) are a bunch of consecutive addresses.

It's up to the program to display them, it could display them completely random if it wants. That's no proof of how the memory is actually looking like.

kohlrak wrote:
So, i guess your excuse for everything now will be, "it came from big endian and intel adopted them."
Shifting was a concept well before Intel processors me thinks. And I think they used a big endian notation for shifting -- i.e shifting right resulted in division by powers of 2. And yes, if you have a beef with little endian, it's ONLY the shifting that you should have with. If you are rational of course.

kohlrak wrote:
Ah, so multiplication and dividing via shifting isn't efficient at all. Glad you told me. I didn't know there were so many more algorithms where broken shifting worked more efficiently.
What the fuck mate, are you doing this on purpose? You are speaking utter nonsense.

When the fuck did efficiency got into the discussion? I meant that shifting has a notion of sense and that's it. the instructions are called shift right and shift left, that's ALL there is to what I was talking about.

The flip-flops composing registers on the CPU could be placed in a circle, or random, or whatever. "right" and "left" make no sense there, it's only the instruction name, a fucking NAME, that's backwards.

How the fuck does a name affect efficiency?

kohlrak wrote:
If you look at the statements, they're no more or less valid than yours, simply because of what another user said, it's pretty much like left-handedness vs right-handedness. I disagree for 2 reasons, but aside from those, it's true.
uhm not really, it's more like whether you assign low to low and high to high (little endian), which is more consistent, or decide to assign them low to high and high to low, for some obscure reason. Wink

kohlrak wrote:
Wow! This is new! I never heard of this! So no wonder why i can't even view my program in a hex editor! So that's why i need an assembler to make my program run! Wow, that's so cool!
uh... ok... not sure what you're saying. You mean a hex editor DISPLAYS YOUR FUCKING CPU? Is there a FUCKING CAMERA that a hex editor uses to look at your CPU or memory in RAM?

Seriously man, go to information theory kindergarten and learn something.

I'm gonna say this one last time: ALL THE HEX FUCKING EDITOR KNOWS IS A BUNCH OF ADDRESSES ASSIGNED TO SPECIFIC PHYSICAL LOCATIONS OF YOUR RAM STICKS OR WHATEVER. IT'S UP TO THE HEX FUCKING EDITOR TO DECIDE WHAT TO DO WITH THEM. IT COULD DISPLAY THEM RANDOMLY, IT COULD DISPLAY THEM FROM HIGHEST TO LOWEST, FROM LOWEST TO HIGHEST, FROM MIDDLE TO LOWEST THEN HIGHEST, HOWEVER IT FUCKING WANTS. THAT'S NO FUCKING PROOF OF HOW IT ACTUALLY IS, BECAUSE THERE ACTUALLY IS NO FUCKING INFORMATION REGARDING THE FUCKING ORDER/DIRECTION/SENSE. IT'S JUST ADDRESSES.

NIGHT GOGGLES COULD DISPLAY INFRARED WITH RED, BLUE, GREEN, GRAY, WHITE, PURPLE, X-RAYS, GAMMA RAYS, WHATEVER IT FUCKING WANTS. JUST BECAUSE THEY DISPLAY IT AS GREEN, BECAUSE THE HUMAN EYE IS SENSITIVE TO IT (WHICH IS A FUCKING MEASURABLE ARGUMENT THAT I'M ASKING YOU TO GIVE ME FOR BIG ENDIAN), NOT BECAUSE THE FUCKING INFRARED ACTUALLY LOOKS LIKE GREEN.


I've said this the LAST fucking time (I think I've said it at least 5 times), you either comprehend it, or stop bothering me with constant nonsense.

kohlrak wrote:
Ah, now you understand what i was getting at! You were making "arguments," but alas they were only unfounded claims, as usual.
That's why you never addressed them. I gave comparative measurable analytical examples, and consistent examples.

as usual, you ignore them. as usual, you don't present ANY argument yourself apart from calling mine bullshit. Isn't that how trolls operate?

kohlrak wrote:
What arguments?
Tell me something, do you find more consistency in assigning 1 to 4 and 4 to 1 and 2 to 3 and 3 to 2 (big endian) than 1 to 1, 2 to 2, 3 to 3 and 4 to 4?

Maybe i should repeat this until the 42th time for you to stop ignoring it.

kohlrak wrote:
X can support more values in less digits. Throw away the fact that no-one can read it, but it's more efficient digit wise. Razz I guess everyone'll have to get over their cultural bais and get used to using X based numbers. (This sounds even more rediculous if you have a base 1024 number system.)
What do you mean more values in less digits?

0 and 1 need only 1 bit to be stored, two NAND gates for a flip flop, etc... how many does your base X require?

kohlrak wrote:
Not just memory addresses. And if you continue ignoring what i'm saying lest you can ignorantly respond to it as before, this argument will just end with you spilling more junk to forum members who aren't going to bother reading your crap.
As usual, when trolls can't back up their arguments which you never ever did (you only attack mine/call mine crap), they resort to personal insults because they can't respond in a way to be analytically measured.
kohlrak wrote:
After reading this bullshit
see? Wink

_________________
Previously known as The_Grey_Beast
Post 27 Dec 2009, 20:15
View user's profile Send private message Reply with quote
mattst88



Joined: 12 May 2006
Posts: 260
Location: South Carolina
mattst88
kohlrak, I don't understand you.

At times you seem like a really smart and knowledgeable guy. In others, you seem to get too caught up in arguments to be able to understand the issue at hand. When this happens, your strategy appears to become drown the other person in incomprehensible text and wage a war of attrition.

I've tried (I say tried, because I really cannot make it all the way through your posts) to read through all of this thread, but it's just impossible. The farther in I go, the more you resort to ad hominem and strawman attacks.
Post 27 Dec 2009, 22:22
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
I apologize myself for getting a bit worked up over it. I know I sweared but trust me I never sweared or insulted anyone, I'm only swearing for emphasis because I'm a bit pissed over the discussion going in circles and me typing the same thing over and over again.

kohlrak, please understand that I have nothing with you, and all my swearings above may be offensive but not insulted anyone. This is one of my favorite communities, I like all of you guys Laughing
Post 27 Dec 2009, 22:56
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
We have already established that multi-byte operations on x86 are natively LE. Without further complexity, the native bit order is 01234567 for the BT* instructions - also LE.


Assumed, not established. If it were to be established, binaries for big-endian machines would have reversed values in hex editors. Only the bytes are swapped. The BT instruction indexes start from the... right... Right?

mattst88 wrote:
At times you seem like a really smart and knowledgeable guy. In others, you seem to get too caught up in arguments to be able to understand the issue at hand. When this happens, your strategy appears to become drown the other person in incomprehensible text and wage a war of attrition.


There's a fine between where there is a reasonable argument and where the argument breaches into rediculousness. I tend to resort to namecalling only after it reaches what i feel to be rediculous. And that only happens when people are too lazy to think about my argument or even think beyond their assumptions. Once someone makes an assumption, it becomes "established." Do I have to sit here and code entire programs (regardless of size) for goons who are too lazy to do so themselves?

Quote:
I've tried (I say tried, because I really cannot make it all the way through your posts) to read through all of this thread, but it's just impossible. The farther in I go, the more you resort to ad hominem and strawman attacks.


Because it has gotten rediculous. Since you seem to be more resonable than the others right now (who absolutely refuse to do what i tell them), i have went out of my way to make a program to point out that their logic of the bits within the registers are reversed. I took a specific number (0x6F6F6F6F [every byte is 01101111b]) which i used the BE<->LE conversion instruction (bswap) on. Low and behold, the result happens to be the same number. So either bswap is broken, it doesn't convert BE<->LE, or their establishment is false. I'm going for the latter.

Code:
format pe console
include 'win32ax.inc'

dummydword dd 01101111011011110110111101101111b
debug db "%i", 10, 0

section '.text' code readable executable data writeable

entry $
cinvoke printf, debug, [dummydword]
 mov eax, [dummydword]
       bswap eax
cinvoke printf, debug, eax
invoke       ExitProcess, 0

section '.idata' import data readable writeable

library kernel32,'KERNEL32.DLL', libc, 'crtdll.dll'

import kernel32, ExitProcess,'ExitProcess'

import libc, printf,'printf'    


And before anyone says that it's the second... I have this quote from the fasm manual. Saying it's the second would be saying Thomasz is wrong. Wouldn't be unusual for an ordinary person to make mistakes, but i would assume Thomasz to have an idea what he's talking about.

Quote:
bswap reverses the byte order of a 32–bit general register: bits 0 through 7
are swapped with bits 24 through 31, and bits 8 through 15 are swapped with
bits 16 through 23. This instruction is provided for converting little–endian
values to big–endian format and vice versa.


borsuc wrote:
I apologize myself for getting a bit worked up over it. I know I sweared but trust me I never sweared or insulted anyone, I'm only swearing for emphasis because I'm a bit pissed over the discussion going in circles and me typing the same thing over and over again.


You think you're pissed about things going in circles and typing the same thing over again...
Post 28 Dec 2009, 01:04
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17260
Location: In your JS exploiting you and your system
revolution
I've always understood endian in computers to be about the byte order, not the bit order within each byte.
Post 28 Dec 2009, 01:37
View user's profile Send private message Visit poster's website Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
kohlrak wrote:
Because it has gotten rediculous. Since you seem to be more resonable than the others right now (who absolutely refuse to do what i tell them), i have went out of my way to make a program to point out that their logic of the bits within the registers are reversed. I took a specific number (0x6F6F6F6F [every byte is 01101111b]) which i used the BE<->LE conversion instruction (bswap) on. Low and behold, the result happens to be the same number. So either bswap is broken, it doesn't convert BE<->LE, or their establishment is false. I'm going for the latter.
Let's see:

0x6F6F6F6F

Address 0: 6F
Address 1: 6F
Address 2: 6F
Address 3: 6F

Little Endian load of value at address:

Byte 0 = Address 0 = 6F
Byte 1 = Address 1 = 6F
Byte 2 = Address 2 = 6F
Byte 3 = Address 3 = 6F

Big Endian load of value at address:

Byte 0 = Address 3 = 6F
Byte 1 = Address 2 = 6F
Byte 2 = Address 1 = 6F
Byte 3 = Address 0 = 6F

hmm... bswap:

Byte 0 = Byte 3
Byte 1 = Byte 2
Byte 2 = Byte 1 (original)
Byte 3 = Byte 0 (original)

to be honest I don't see any problem with bswap. I do see a backwards count in big endian though, starting with low bytes but high addresses in memory.

if you still don't see why it's backwards, imagine a 'for' loop that makes all of this correspondings:

Little-Endian:
Code:
for i=0 to number_of_bytes_in_value do Byte i corresponds to Address i    
Big-Endian:
Code:
for i=0 to number_of_bytes_in_value do Byte i corresponds to Address (number_of_bytes_in_value-i)    
hmm I wonder which one is less consistent and more backwards.

Of course you need bswap for conversion, one of them is backwards and it's obvious which from an algorithmical and rational point of view.

_________________
Previously known as The_Grey_Beast
Post 28 Dec 2009, 02:03
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Sorry if this was said already and I missed it but what is the order at the bit level? I mean, lets say I have the number $01018080 and I do BSWAP on it, I'm guaranteed that a big-endian processor (I mean those that are/were commercially available, not theoretical too), will make the number zero if I subtract $01018080 instead of giving me, say, 7F7E8081?

Or perhaps this is always solved by something else and for that reason BSWAP allows data to be safely interpreted by the foreign architecture?

If not the case then how to know which one is "breaking the natural order"? If Intel saves a 16-bit word like [0-7][8-15], does it follows that Motorola 68020 saves a 16-bit word like [8-15][0-7] instead of [15-8][7-0]?

And yes, I also don't understand how I have this doubt at this age... Confused
Post 28 Dec 2009, 02:44
View user's profile Send private message Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Borsuc wrote:
kohlrak wrote:
Because it has gotten rediculous. Since you seem to be more resonable than the others right now (who absolutely refuse to do what i tell them), i have went out of my way to make a program to point out that their logic of the bits within the registers are reversed. I took a specific number (0x6F6F6F6F [every byte is 01101111b]) which i used the BE<->LE conversion instruction (bswap) on. Low and behold, the result happens to be the same number. So either bswap is broken, it doesn't convert BE<->LE, or their establishment is false. I'm going for the latter.
Let's see:

0x6F6F6F6F

Address 0: 6F
Address 1: 6F
Address 2: 6F
Address 3: 6F

Little Endian load of value at address:

Byte 0 = Address 0 = 6F
Byte 1 = Address 1 = 6F
Byte 2 = Address 2 = 6F
Byte 3 = Address 3 = 6F

Big Endian load of value at address:

Byte 0 = Address 3 = 6F
Byte 1 = Address 2 = 6F
Byte 2 = Address 1 = 6F
Byte 3 = Address 0 = 6F

hmm... bswap:

Byte 0 = Byte 3
Byte 1 = Byte 2
Byte 2 = Byte 1 (original)
Byte 3 = Byte 0 (original)

to be honest I don't see any problem with bswap. I do see a backwards count in big endian though, starting with low bytes but high addresses in memory.

if you still don't see why it's backwards, imagine a 'for' loop that makes all of this correspondings:

Little-Endian:
Code:
for i=0 to number_of_bytes_in_value do Byte i corresponds to Address i    
Big-Endian:
Code:
for i=0 to number_of_bytes_in_value do Byte i corresponds to Address (number_of_bytes_in_value-i)    
hmm I wonder which one is less consistent and more backwards.

Of course you need bswap for conversion, one of them is backwards and it's obvious which from an algorithmical and rational point of view.


This addresses the "bits within a byte are reversed" argument. I won't bother with your last argument reply, because you did what i said would get you simply ignored, just like the last argument. Your inferiority complex (or whatever the hell you have) where you think you're always right and refuse to acknowledge arguments by imposing a double standard (no bias, quantitative examples, etc), followed by the lack of common sense. Ex:

Quote:
You know calling me stupid won't change the fact that all your arguments are loose, non-concrete, and unmeasurable. "dw AB" doesn't compile, unless AB is defined as a variable. If you say 'A' is at the lowest address and 'B' is at the highest, then "dw 'AB'" or "db 'AB'" represents that. If you say 'A' is at the high address and 'B' at the lowest, then db 'BA' represents that.


When i said AB no as a string, i meant if A represent 0xFE and B represent 0x84 (yes, i came up with those numbers off the top of my head), then "dw AB" would be "dw 0xFE84," which, i don't see how the way i put it so damn difficult for you to come to such the conclusion here. Do I actually have to spell it all out for you? Perhaps you would prefer for me to waste my time writing another program (no matter how small), when i'd rather be doing something else, simply because you're too lazy to think about what i'm saying, and say it's "unrelated," "doesn't make sense" or some other thing so you don't have to bother... Well, to hell with that. Razz I'm not wasting any more time on you.

EDIT:

LocoDelAssembly wrote:
Sorry if this was said already and I missed it but what is the order at the bit level? I mean, lets say I have the number $01018080 and I do BSWAP on it, I'm guaranteed that a big-endian processor (I mean those that are/were commercially available, not theoretical too), will make the number zero if I subtract $01018080 instead of giving me, say, 7F7E8081?

Or perhaps this is always solved by something else and for that reason BSWAP allows data to be safely interpreted by the foreign architecture?

If not the case then how to know which one is "breaking the natural order"? If Intel saves a 16-bit word like [0-7][8-15], does it follows that Motorola 68020 saves a 16-bit word like [8-15][0-7] instead of [15-8][7-0]?

And yes, I also don't understand how I have this doubt at this age... Confused


Either bswap is broken or the bit order within 1 byte of a big-endian number is the same as a 1 byte little-endian number.


Last edited by kohlrak on 28 Dec 2009, 02:47; edited 2 times in total
Post 28 Dec 2009, 02:44
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
sinsi



Joined: 10 Aug 2007
Posts: 692
Location: Adelaide
sinsi
Maybe intel should make their next cpu's bi-endian Smile
Then we can see who wins...
Post 28 Dec 2009, 02:55
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4  Next

< 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 can attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.