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
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
For bignums, if you set a hard limit then the programs that use them would be almost useless.


And typically they are useless. A program or routine without a hard limit is typically very, very inefficient to begin with (due to fragmenting, having to move all the data anyway due to lack of room to simply allocate bytes [as opposed to them being already allocated for it anyway]). You know though, if this is really such a problem, learn to use a stack instead of an array. Only on a theoretical and impractical machine would you be able to infinately grow an array up, so why not just grow an array like a stack, and grow down from the maximum. Belive it or not, this would make sense from a cultural standpoint as well (if you have a pile of something, you take away the stuff at the top before taking away the stuff at the bottom, because it's much easier). If you're gonna run out of ram in your page, section, or all together, you'll have to reallocate and move irregardlessly, so i dont' see what the problem is.

Quote:
As for partial bytes, if you think of the ordering scheme as numbered from the left towards the right then of course you will think LE is wrong. But if you put zero at the right and number successively towards the left then the numbering is nice. Like I mentioned above, the cultural custom of writing numbers in decimal as BE is creating the confusion. You might tend to think of the first digit at the MSD but you are also numbering that the zeroth digit. That is kind of like alice-in-wonderland style Razz. But, if we have the LSD numbered as zero and higher significant digits at higher addresses it seems very logical to me.


If there was only big endian and little endian, there would be no confusion, except in teaching the initial system of reading the other way. Anyway, as stated before (i don't know why my counter argument was ignored), the internal bits are in big endien. Unless of course, you show me that I am wrong and that those various double endian formats need a much more complex macro to deal with than the one i have been using:

Code:
struc BEDD number {
  db number and 0xFF
  db (number shr 8) and 0xFF
  db (number shr 16) and 0xFF
 db (number shr 24) and 0xFF }    


Although i don't happen to have anything handy that i'm 100% sure checks the big endian part of an ISO file, the ISO file (generated using that for the big endian conversion) does seem to work.

revolution wrote:
For LE:
mov al,byte[number+0] is the LSB
mov ax,word[number+0] is the LSW
mov eax,dword[number+0] is the LSD
mov rax,qword[number+0] is the LSQ

For BE:
mov al,byte[number+0] is ?. It depends upon the bus width
mov ax,word[number+0] is ?. It depends upon the bus width
mov eax,dword[number+0] is ?. It depends upon the bus width
mov rax,qword[number+0] is ?. It depends upon the bus width


For BE:
mov al,byte[number-0] is the LSB
mov ax,word[number-0] is the LSW
mov eax,dword[number-0] is the LSD
mov rax,qword[number-0] is the LSQ

For LE:
mov al,byte[number-0] is ?. It depends upon the bus width
mov ax,word[number-0] is ?. It depends upon the bus width
mov eax,dword[number-0] is ?. It depends upon the bus width
mov rax,qword[number-0] is ?. It depends upon the bus width

Quote:
LE makes sense when you consider
byte[0] is 256^0
byte[1] is 256^1
etc.


Indeed that does make sense. But for the sake of the "it's cultural" argument, we're just too stuck as a culture to treat allocated memory as stacks growing down instead of arrays going up, since we tend to teach it more as an elevator rather than available memory.
Post 23 Dec 2009, 08:33
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: 2915
Location: [RSP+8*5]
bitRAKE
kohlrak , finally getting to the meat of your argument. Cultual bias and moving data around. I totally agree on the cultual bias - stubbling over that hurdle myslef. Data doesn't have to be physically moved due to paging. So, it's a wash - know what you're dealing with and do what is required to make it happen. Try to use the BT* instructions to plot a bit field - how the video API (GDI, DX, whaever) interprets the data will impact the bit indexing transformation.
Post 23 Dec 2009, 08:57
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: 17279
Location: In your JS exploiting you and your system
revolution
kohlrak wrote:
For BE:
mov al,byte[number-0] is the LSB
mov ax,word[number-0] is the LSW
mov eax,dword[number-0] is the LSD
mov rax,qword[number-0] is the LSQ

For LE:
mov al,byte[number-0] is ?. It depends upon the bus width
mov ax,word[number-0] is ?. It depends upon the bus width
mov eax,dword[number-0] is ?. It depends upon the bus width
mov rax,qword[number-0] is ?. It depends upon the bus width
I assume you are using 'number' as pointing to the highest byte address? If so the your description of LE is not correct.

LE with 'number' pointing to highest address.
mov al,byte[number-0] is the MSB
mov ax,word[number-0] is the MSW
mov eax,dword[number-0] is the MSD
mov rax,qword[number-0] is the MSQ
Post 23 Dec 2009, 09:28
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:
kohlrak , finally getting to the meat of your argument. Cultual bias and moving data around. I totally agree on the cultual bias - stubbling over that hurdle myslef. Data doesn't have to be physically moved due to paging. So, it's a wash - know what you're dealing with and do what is required to make it happen. Try to use the BT* instructions to plot a bit field - how the video API (GDI, DX, whaever) interprets the data will impact the bit indexing transformation.


Not paging itself. My point is, if you allocate room for something and continue allocating data for that something, you're eventually going to run into something else (code, other data, ram boundry, etc). No matter where you start, no matter what endianness you use, you will run into that problem. The idea is to plan ahead.

Quote:
I assume you are using 'number' as pointing to the highest byte address? If so the your description of LE is not correct.

LE with 'number' pointing to highest address.
mov al,byte[number-0] is the MSB
mov ax,word[number-0] is the MSW
mov eax,dword[number-0] is the MSD
mov rax,qword[number-0] is the MSQ


Ah, this is true indeed. I will, once again, parody your comment (not to be impolite, but to make a point)...

Revolution wrote:
For LE:
mov al,byte[number+0] is the LSB
mov ax,word[number+0] is the LSW
mov eax,dword[number+0] is the LSD
mov rax,qword[number+0] is the LSQ

For BE:
mov al,byte[number+0] is ?. It depends upon the bus width
mov ax,word[number+0] is ?. It depends upon the bus width
mov eax,dword[number+0] is ?. It depends upon the bus width
mov rax,qword[number+0] is ?. It depends upon the bus width


I assume you are using 'number' as pointing to the lowest byte address? If so the your description of BE is not correct.

BE with 'number' pointing to lowest address.
mov al,byte[number+0] is the MSB
mov ax,word[number+0] is the MSW
mov eax,dword[number+0] is the MSD
mov rax,qword[number+0] is the MSQ

The problem is, since you are right, to some degree about this being like left hand and right hand, mostly anything you try to do to make LE better than BE can easily be swapped around to make the same argument. Thus pointing out, little endian doesn't make more sense than big endian from a programmer standpoint. If anything, what was said before is true that big endian is more natural for those of us who are used to writing "one hundred" as "100."
Post 23 Dec 2009, 10:16
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
my old article might demonstrate some things mentioned here: http://x86asm.net/articles/working-with-big-numbers-using-x86-instructions/index.html

I agree that LE is nicer.

However, did the names LE and BE seem to be used in "opposite" way to you (as they seem to me)?

I mean, in little endian number, you would expect the number to "end" with "little" part. However, in reality the "end" (highest address) stores the most-significant part ("the biggest"). Maybe that's again influence of he we write numbers?
Post 23 Dec 2009, 12:43
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
endian. End can be either the front or the back. First or last. Beginning or ending, oops Embarassed

Front-end loader?

Back-end server?

From one end to the other?

Going end over end?
Post 23 Dec 2009, 12:48
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:
BE with 'number' pointing to lowest address.
mov al,byte[number+0] is the MSB
mov ax,word[number+0] is the MSW
mov eax,dword[number+0] is the MSD
mov rax,qword[number+0] is the MSQ
but for big endian to make sense, 'al' would have to be the upper byte of the register...

this is wrong on many levels. If you extend the register size (say to 128 bits), 'al' would move! This doesn't happen with little endian since it's the more logical choice.

This is why:

let's say we have the text 'ABCD' and we use big endian to get this.

getting 1 byte puts 'A' into al (lowest byte)
getting 2 bytes puts 'A' into ah and 'B' into 'al'. WRONG

in this case 'al' must be the highest byte in the register for it to work properly. 'ax' must be the upper word. Again this is a bad approach.

Big Endian's biggest problem is that a lot of shit changes if you change the size.

I've yet to see any benefit out of big endian from a scientific point of view.

kohlrak wrote:
The problem is, since you are right, to some degree about this being like left hand and right hand, mostly anything you try to do to make LE better than BE can easily be swapped around to make the same argument. Thus pointing out, little endian doesn't make more sense than big endian from a programmer standpoint. If anything, what was said before is true that big endian is more natural for those of us who are used to writing "one hundred" as "100."
No, no and no. Wink

What makes more sense, that as you increase memory address you go higher up the number or lower?

[number+0] is least significant. +1 is more significant. This only makes sense. In Big Endian you have to know the size in advance.

And besides, seriously, saying bignums are worthless is no argument. I've yet to see where big endian is better, capability-wise. Bignums are easier in little endian. Actually a lot of variable-sized numbers are easy in little endian.

Little endian is also easier on the circuitry where 'al' uses lower byte of the register. (it uses same bus as when getting a WORD or DWORD)... again, if 'al' were to use the highest register, things would go havoc when you change the size...


I'd say, if you want "cultural norm" go and use decimal inefficient computers. Little endian and bits are reserved for those of us who want efficient methods not cultural drawbacks. Smile

Oh also, you can reserve pages in memory (address space), you don't have to commit them.

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



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
Quote:
Quote:
LE with 'number' pointing to highest address.
mov al,byte[number-0] is the MSB
mov ax,word[number-0] is the MSW
mov eax,dword[number-0] is the MSD
mov rax,qword[number-0] is the MSQ


but for little endian to make sense, 'al' would have to be the lower byte of the register...

this is wrong on many levels. If you extend the register size (say to 128 bits), 'al' would move! This doesn't happen with big endian since it's the more logical choice.


As a side note, do this to yourself before making the comment, it'll save me some time responding to you. The reason this works is, your endian thing works because the register itself is little endian. If x86 wasn't little endian but big endian, my point would be valid for it.

Quote:
This is why:

let's say we have the text 'ABCD' and we use big endian to get this.

getting 1 byte puts 'A' into al (lowest byte)
getting 2 bytes puts 'A' into ah and 'B' into 'al'. WRONG


Strings are not a single number. Strings are a LE array of 1 byte numbers. Your logic here is flawed, because text is inherently LE. If i stored a big endian number, retrieving it with little endian would also cause a similar problem. If strings were reversed, this problem would be reversed. Treating a string as a single number is not a very practical situation, for if you wanted a number, you'd have a number. If you wanted a string, you'd have a string. At most, you could argue about how efficient string to number conversion is.

Now, since i'm annoyed at the consistent stupidity of this argument even continuing anymore (I already stated the advantages and disadvantages of both, and even am in support of little endian to some degree for speed bonuses, however you're just making up stuff to win an argument):

Quote:
Little Endian's biggest problem is that a lot of shit changes if you change the size.

I've yet to see any benefit out of little endian from a scientific point of view.


Quote:
What makes more sense, that as you increase memory address you go higher up the number or lower?


I thought we had to get past our cultural bias of doing things in one direction and not another.

Quote:
[number-0] is least significant. -1 is more significant. This only makes sense. In Little Endian you have to know the size in advance.


Razz

Quote:
And besides, seriously, saying bignums are worthless is no argument.


Not worthless, but often not necessary.

Quote:
I've yet to see where little endian is better, capability-wise. Bignums are easier in big endian. Actually a lot of variable-sized numbers are easy in big endian.


Razz

Quote:
Big endian is also easier on the circuitry where 'al' uses lower byte of the register. (it uses same bus as when getting a WORD or DWORD)... again, if 'al' were to use the highest register, things would go havoc when you change the size...


You see, the problem with your statement is that with big endian, al is the rightmost register, which would be the lowest register. You see, you extend things on the left instead of the right with big endian.

Quote:
I'd say, if you want "cultural norm" go and use decimal inefficient computers. Big endian and bits are reserved for those of us who want efficient methods not cultural drawbacks. Smile


Depends on what efficient is.

This debate and the others makes me wonder whether you use windows 7 or an older version. It seems to me that you would most likely use the newest windows, since it's obviously better than the previous versions. I mean common, you want to upgrade to have the latest and greatest, instead of cultural (we know the older versions better, they're faster, more stable, etc) drawbacks.

Quote:
Oh also, you can reserve pages in memory (address space), you don't have to commit them.


And what does that have to do with anything? It doesn't avoid the point that no matter which way it grows, it'll hit something.
Post 24 Dec 2009, 03:09
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
kohlrak wrote:
As a side note, do this to yourself before making the comment, it'll save me some time responding to you. The reason this works is, your endian thing works because the register itself is little endian. If x86 wasn't little endian but big endian, my point would be valid for it.
huh?

mov al, [address]
mov ax, [address] <-- this should put the same byte in al, but also another (new) byte in ax

let's say the value at address is 'AB' and the register starts with 0

Little Endian with al on the LSB:
Code:
|0|A|
|B|A|    
Big Endian with al on the LSB:
Code:
|0|A|  <-- ok
|A|B|  <-- BAD    
don't you see?

It has to be on the highest, i.e al on the MSB in this 16-bit register case:
Code:
|A|0|
|A|B|    
but what happens when you...
Code:
|0|0|A|0|
|0|0|A|B|
|A|B|C|D|  <-- BAD    
Wink

kohlrak wrote:
Strings are not a single number. Strings are a LE array of 1 byte numbers. Your logic here is flawed, because text is inherently LE. If i stored a big endian number, retrieving it with little endian would also cause a similar problem. If strings were reversed, this problem would be reversed. Treating a string as a single number is not a very practical situation, for if you wanted a number, you'd have a number. If you wanted a string, you'd have a string. At most, you could argue about how efficient string to number conversion is.
WHAT? You never parse strings with more than 1 byte at a time? With the above in mind it's obvious little endian has an advantage where there is no equivalent advantage to big endian. I don't care whether you use this advantage or not, but tell me what does big endian have, objectively speaking in comparison so it can even out?

You can't say cultural norms because those are subjective and I could say little endian is more "beautiful", for instance. But something concrete like the above... Wink

kohlrak wrote:
Little Endian's biggest problem is that a lot of shit changes if you change the size.

I've yet to see any benefit out of little endian from a scientific point of view.
I just gave two. And how does "shit change" if you change the size in little endian? Can you make some sense instead of mirroring posts pls... that would be great.

kohlrak wrote:
I thought we had to get past our cultural bias of doing things in one direction and not another.
hmm... memory addresses increase in value, that isn't any cultural bias, you know, they are bits and all that actually the CPU uses to address a RAM value.

kohlrak wrote:
[number-0] is least significant. -1 is more significant. This only makes sense. In Little Endian you have to know the size in advance.
the interesting thing is that, when you tell a big endian CPU to fetch a word from memory, it gets it from "address" and "address+1"... Wink whether you like it or not. Razz

whereas a little endian CPU works perfectly.

kohlrak wrote:
Not worthless, but often not necessary.
I agree, however, if there's even one insignificant advantage to something that is not counteracted by any disadvantage (subjectivity doesn't apply) it is always the better choice... no matter how insignificant that advantage is.

kohlrak wrote:
I've yet to see where little endian is better, capability-wise. Bignums are easier in big endian. Actually a lot of variable-sized numbers are easy in big endian.
Explain.

kohlrak wrote:
You see, the problem with your statement is that with big endian, al is the rightmost register, which would be the lowest register. You see, you extend things on the left instead of the right with big endian.
??? Question

if 'al' is the lowest register AND the rightmost register then it's little endian, not big endian.

kohlrak wrote:
Depends on what efficient is.
Result Desired / Power Consumption (or otherwise).

kohlrak wrote:
This debate and the others makes me wonder whether you use windows 7 or an older version. It seems to me that you would most likely use the newest windows, since it's obviously better than the previous versions. I mean common, you want to upgrade to have the latest and greatest, instead of cultural (we know the older versions better, they're faster, more stable, etc) drawbacks.
yeah I'm pretty sure big endian is faster and more stable and has a proven track record of scientific analysis... just like the decimal system, binary is such a bloated piece of shit.

Don't be ridiculous, why would I use 7? It's inefficient, bloated, restrictive, bloated, uses too much RAM, bloated, too flashy, bloated, DRM-enforcing-piece-of-shit, BLOATED (did I mention that?).

kohlrak wrote:
And what does that have to do with anything? It doesn't avoid the point that no matter which way it grows, it'll hit something.
With Big Endian you would have to reserve pages backwards and start with the highest page in memory. Like the stack.

The problem is that, what the hell is the benefit with that? It can't be cultural norms, surely you don't read backwards, right?

_________________
Previously known as The_Grey_Beast
Post 24 Dec 2009, 03:43
View user's profile Send private message Reply with quote
DustWolf



Joined: 26 Jan 2006
Posts: 373
Location: Ljubljana, Slovenia
DustWolf
bitRAKE wrote:
Endianness only matters when speaking about how bytes are stored in memory. To use the term with regard to how the processor operates on data internally is incorrect -


AHEM?! I clearly remember the bitwise-endian argument from my electronics classes!

Little-endian bitwise: pinout for bit# is: 0 1 2 3 4 5 6 7

Big-endian bitwise: pinout for bit# is: 7 6 5 4 3 2 1 0

Although I generally side with big-endian, the point that it was used a lot with hardware was something I always hated. So if you ever design a new CPU, you'll use bitwise little-endian (unless you have a brain malfunction that makes you count everything backwards).

On a higher, byte-level endianess level (because real life things are not always register-width aligned) it makes a lot of sense to use a endian-format that makes bits in memory sequential rather than shuffled around like crazy.

As far as I can tell little-endian is this crazy shuffled around format. Forget how we write numbers, take a string "ABCD", you'd expect it to be stored in memory as "ABCD" so that you can append it with "EF" and be done with "ABCDEF", but noo... it's stored as "CDAB" and appending it with "EF" produces the gibberish output "CDABEF" or "CDAB00EF" depending on how you phrased yourself. Say what you want but this format does not make sense!

LP,
Jure
Post 25 Dec 2009, 00:13
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
@DustWolf: your example, beside being silly, is wrong. Razz

think of memory as bytes, not as strings, and little-endian makes much more sense than big-endian.

Do you count with the lowest byte first or the highest?

It is you who is making this look complicated, because you start from the highest byte, but lowest memory. Don't you see why big endian is a failure -- why start with highest byte in register but lowest memory address?

It doesn't make any sense no matter how you put it. End of story.

i.e you expect the highest byte 'A' from 'ABCD' to be put in the lowest address of this 4-byte sequence...

logically it makes no sense whatsoever, it's backwards.

_________________
Previously known as The_Grey_Beast
Post 25 Dec 2009, 01:07
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:
As a side note, do this to yourself before making the comment, it'll save me some time responding to you. The reason this works is, your endian thing works because the register itself is little endian. If x86 wasn't little endian but big endian, my point would be valid for it.
huh?

mov al, [address]
mov ax, [address] <-- this should put the same byte in al, but also another (new) byte in ax


No it wouldn't. If x86 was big endian, al would be on the right side not the left side. The position of ah and al is because it's little endian.

Quote:
let's say the value at address is 'AB' and the register starts with 0

Little Endian with al on the LSB:
Code:
|0|A|
|B|A|    


Wrong... If you declare "dw AB", it's stored the same as "db B, A." Therefore...

Little Endian with al on the LSB:
Code:
|A|0|
|B|A|    


Quote:
Big Endian with al on the LSB:
Code:
|0|A|  <-- ok
|A|B|  <-- BAD    
don't you see?


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|    


Quote:
[code]It has to be on the highest, i.e al on the MSB in this 16-bit register case:[code]|A|0|
|A|B|[/code]but what happens when you...[code]|0|0|A|0|
|0|0|A|B|
|A|B|C|D| <-- BAD[/code]Wink


Read above, and i will not have to talk about that.

Quote:
kohlrak wrote:
Strings are not a single number. Strings are a LE array of 1 byte numbers. Your logic here is flawed, because text is inherently LE. If i stored a big endian number, retrieving it with little endian would also cause a similar problem. If strings were reversed, this problem would be reversed. Treating a string as a single number is not a very practical situation, for if you wanted a number, you'd have a number. If you wanted a string, you'd have a string. At most, you could argue about how efficient string to number conversion is.
WHAT? You never parse strings with more than 1 byte at a time? With the above in mind it's obvious little endian has an advantage where there is no equivalent advantage to big endian. I don't care whether you use this advantage or not, but tell me what does big endian have, objectively speaking in comparison so it can even out?


Even WHAT out? You only parse strings one byte at a time. It's a string, trying to parse more than one at a time results in error, because a string is an array of bytes. If you're only copying (the only thing you should be doing with more than one byte at a time with a string), there's no problem.

Quote:
You can't say cultural norms because those are subjective and I could say little endian is more "beautiful", for instance. But something concrete like the above... Wink


Um... Of course it's subjective. That's the point i'm trying to make...

Quote:
kohlrak wrote:
Little Endian's biggest problem is that a lot of shit changes if you change the size.

I've yet to see any benefit out of little endian from a scientific point of view.
I just gave two. And how does "shit change" if you change the size in little endian? Can you make some sense instead of mirroring posts pls... that would be great.


First off, you gave only one. Secondly, it was discredited, so we're moving on (or hopefully terminating this crap).

Quote:
kohlrak wrote:
I thought we had to get past our cultural bias of doing things in one direction and not another.
hmm... memory addresses increase in value, that isn't any cultural bias, you know, they are bits and all that actually the CPU uses to address a RAM value.


They could start at "max" and go down. It's up to you how you make your array. We have two types of arrays. Forward arrays and a stack. Since both are useful, intel even made the "string instructions" go both directions, believe it or not. That's why we have things thing called a "direction flag." And for other types of reverse arrays (stack), we have the push and pop instructions.

Quote:
kohlrak wrote:
[number-0] is least significant. -1 is more significant. This only makes sense. In Little Endian you have to know the size in advance.
the interesting thing is that, when you tell a big endian CPU to fetch a word from memory, it gets it from "address" and "address+1"... Wink whether you like it or not. Razz


That's why you give it a -1 when grabbing a word. Or actually, you could also grab a byte from a dword with an address+3. Or is that too complicated for you?

Quote:
whereas a little endian CPU works perfectly.


It's not the CPU, it's the language for talking to it. Did you know they use numbers on big endian CPUs instead? Wow! Isn't that neat!? Now we can say that big endian CPUs "don't work perfectly" because we learned something new. Biggy boy, now things make sense don't they!?

Quote:
kohlrak wrote:
Not worthless, but often not necessary.
I agree, however, if there's even one insignificant advantage to something that is not counteracted by any disadvantage (subjectivity doesn't apply) it is always the better choice... no matter how insignificant that advantage is.


If subjectivity doesn't apply, would you like me to go to town on the direction of strings? How about offsets always being in the negative instead of the positive? How numbers should be the upper bounds instead of the lower bounds? Subjective things indeed.

Quote:
kohlrak wrote:
I've yet to see where little endian is better, capability-wise. Bignums are easier in big endian. Actually a lot of variable-sized numbers are easy in big endian.
Explain.


i was just making the same ridiculous (and wrong) statement you were making. How ridiculous did i sound? Now think, all i did was reverse yours. Try and guess how ridiculous yours sounded! I'll give you a clue, "!lanoitroporp ylsrevni"

Quote:
kohlrak wrote:
You see, the problem with your statement is that with big endian, al is the rightmost register, which would be the lowest register. You see, you extend things on the left instead of the right with big endian.
??? Question


Of course you don't understand, because you don't understand little endian either! Exclamation

Quote:
if 'al' is the lowest register AND the rightmost register then it's little endian, not big endian.


Your other right! AL is the lowest register, which to be little endian, it must be on the left, which happens to be this way! ← Or don't you know your left from your right?

← is left and → is right! By the way, it's the directions that is the most edgy in which they point to. Also, if you stick your hands up, and you want to know which hand is the left hand, it's the one where the front (the part that's convex not concave [if those words aren't too big for you]) faces you and makes an L with your finger and your them. You can remember this because L is for left.

Quote:
kohlrak wrote:
Depends on what efficient is.
Result Desired / Power Consumption (or otherwise).


And how do we make this into a number again?

Quote:
kohlrak wrote:
This debate and the others makes me wonder whether you use windows 7 or an older version. It seems to me that you would most likely use the newest windows, since it's obviously better than the previous versions. I mean common, you want to upgrade to have the latest and greatest, instead of cultural (we know the older versions better, they're faster, more stable, etc) drawbacks.
yeah I'm pretty sure big endian is faster and more stable and has a proven track record of scientific analysis... just like the decimal system, binary is such a bloated piece of shit.


Correct! Big endian has been around for more than 2000 years! It's been around for longer than computers, actually.

Quote:
Don't be ridiculous, why would I use 7? It's inefficient, bloated, restrictive, bloated, uses too much RAM, bloated, too flashy, bloated, DRM-enforcing-piece-of-shit, BLOATED (did I mention that?).


You criticize something new!? Can i believe my eyes!? Surprised

Quote:
kohlrak wrote:
And what does that have to do with anything? It doesn't avoid the point that no matter which way it grows, it'll hit something.
With Big Endian you would have to reserve pages backwards and start with the highest page in memory. Like the stack.


Is that a problem? Does it allow you to have more memory to do it the other way?

Quote:
The problem is that, what the hell is the benefit with that? It can't be cultural norms, surely you don't read backwards, right?


Something is inevitably backwords. Big endian is a standard older than you were alive. Then again, so was little endian. Razz

Ok, outside of the personal attack, there is no specific benefit, but this wouldn't be reading backwords either. Memory management is only as old as computers are, so technically that standard is younger than your parents.

Quote:
think of memory as bytes, not as strings, and little-endian makes much more sense than big-endian.


What?

Quote:
It is you who is making this look complicated, because you start from the highest byte, but lowest memory. Don't you see why big endian is a failure -- why start with highest byte in register but lowest memory address?


Good, let's go from high to low! (Name of a good card game for your level of intelligence by the way. It teaches you when to quit as well.)

Quote:
logically it makes no sense whatsoever, it's backwards.


So is little endian.
Post 25 Dec 2009, 04:29
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
DustWolf



Joined: 26 Jan 2006
Posts: 373
Location: Ljubljana, Slovenia
DustWolf
Hrm... I wouldn't go so far as to claim to be right, because little-endian confuses me, however I'm pretty sure my example is right, Borsuc.

I know the shuffling of Intel's litle-endian is easy to conceal if you only operate with the same register size at a time (say, only parse bytewise and only copy dwordwise). But if you ever made a dword-based memcopy that checks for null termination in real-time, you should know exactly how little-endian is shuffled around.

I once helped port an OpenGL application to PowerPC and I know that the moment we got it ported, everything suddenly started making perfect sense in the datafile hex-editor view. When values were written as dwords and read as bytes they would be shuffled around in Intel little-endian, but straight in PowerPC big-endian. That's how I can be sure big-endian makes more sense than little-endian.

LP,
Jure
Post 25 Dec 2009, 05:14
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
DustWolf wrote:
Hrm... I wouldn't go so far as to claim to be right, because little-endian confuses me, however I'm pretty sure my example is right, Borsuc.

I know the shuffling of Intel's litle-endian is easy to conceal if you only operate with the same register size at a time (say, only parse bytewise and only copy dwordwise). But if you ever made a dword-based memcopy that checks for null termination in real-time, you should know exactly how little-endian is shuffled around.

I once helped port an OpenGL application to PowerPC and I know that the moment we got it ported, everything suddenly started making perfect sense in the datafile hex-editor view. When values were written as dwords and read as bytes they would be shuffled around in Intel little-endian, but straight in PowerPC big-endian. That's how I can be sure big-endian makes more sense than little-endian.

LP,
Jure


Which is why pictures explaining the registers look like this:

Code:
+-------------+
|      EAX    |
|    N/A|  AX |
|    N/A|AH|AL|
+-------------+    


Why? Because that's big endian and it makes more sense to more people.
Post 25 Dec 2009, 05:22
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: 693
Location: Adelaide
sinsi
Post 25 Dec 2009, 05:47
View user's profile Send private message Reply with quote
DustWolf



Joined: 26 Jan 2006
Posts: 373
Location: Ljubljana, Slovenia
DustWolf
sinsi wrote:
ON HOLY WARS AND A PLEA FOR PEACE
30 years ago...


Take a good look at the graphs on page 13. Intel's little-endian is the inconsistent one. It DOESN'T make sense. If it applied for bits as well, it would be ambigous, but it's not. it's bitwise bigendian and bytewise little-endian. Inconsistent. Illogical.

I rest my case.
Post 25 Dec 2009, 06:22
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger Reply with quote
kohlrak



Joined: 21 Jul 2006
Posts: 1421
Location: Uncle Sam's Pad
kohlrak
DustWolf wrote:
sinsi wrote:
ON HOLY WARS AND A PLEA FOR PEACE
30 years ago...


Take a good look at the graphs on page 13. Intel's little-endian is the inconsistent one. It DOESN'T make sense. If it applied for bits as well, it would be ambigous, but it's not. it's bitwise bigendian and bytewise little-endian. Inconsistent. Illogical.

I rest my case.


As a side note, this isn't a war between me and borsuc about which is better. I am actually on the side of little-endian, for the sake of cheaper CPU hardware. Inconsistency between bits and byte order makes less sense (as stated) but makes CPU cheaper because you can simply shift the operation instead of making separate parts to do your ops of different sizes. Borsuc is just pushing my buttons. Razz
Post 25 Dec 2009, 06:27
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger Reply with quote
tom tobias



Joined: 09 Sep 2003
Posts: 1320
Location: usa
tom tobias
sinsi wrote:
ON HOLY WARS AND A PLEA FOR PEACE
30 years ago...
If I am not badly mistaken, IBM introduced the System 360 in the mid 1960's, i.e. 45 years ago, not 30.

The system 360 introduced, as I recall, 8 bit bytes, 32 bit words, and byte addressable memory.

A couple of years later, DEC introduced the PDP-10, but I believe that it was a 36 bit machine. I don't know how it moved bytes to memory locations.

The focus on how to represent bytes of data in memory, was a reflection of the fundamental issue facing computer designers in the late 1960's: the high cost of memory. Wasting unneeded precious bits was a bit like wasting water today....

If we had possessed as much memory available to us, forty years ago, (when decisions were being made about the distant future--i.e. the 1970's!!), as we do today, this issue of Endianness would never have arisen, because the smallest addressable chunk of memory would correspond to the register size, i.e. 32 bits--today 64 bits, tomorrow 128 bits...

One can afford to squander memory today. Back then, it was impossible. Ascii characters only needed 8bits, so why waste 24 bits, when each byte cost a measureable sum. What does it cost today for 4 gbytes of dual channel (long since obsolete) DDR2-800 pc2-6400? About $80? How much is that in 1969 terms?$15

How much memory could one purchase in 1969 for 15$?

Intel's 1103, a 1kilobit chip, sold for a penny a bit, i.e. $10, so to answer my question, four decades ago, one could procure 1.5k RAM for $15. Four gigabytes would have cost.....?? forty million dollars, back then, ~~or about 200 million dollars, in terms of today's dollar.

Smile
Post 25 Dec 2009, 14:19
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17279
Location: In your JS exploiting you and your system
revolution
tom tobias: Memory usage (and wastage thereof) is not about cost, it is about performance. More bytes to transfer, because of wastage, equates to loss of performance overall. We already complain about our machines taking so long to boot, so how would we feel when they take 2-3 times longer because we are freely wasting memory with pointless zeros in unused high bits?

The Internet would also be slower with 4 times the data to transfer for text pages that waste bits as pointless zeros in the high bits.
Post 25 Dec 2009, 15:33
View user's profile Send private message Visit poster's website Reply with quote
DustWolf



Joined: 26 Jan 2006
Posts: 373
Location: Ljubljana, Slovenia
DustWolf
revolution wrote:
The Internet would also be slower with 4 times the data to transfer for text pages that waste bits as pointless zeros in the high bits.


If I am not mistaken, internet traffic data (headers) are not PC-register-width aligned and data is passed to the NIC in big-endian format on PC-based arch (uses bswap).

LP,
Jure
Post 25 Dec 2009, 15:43
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger 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.