flat assembler
Message board for the users of flat assembler.

Index > Heap > Endianness?

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


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
bswap is not broken. It does what it was designed to do, swap bytes.

bit order within a byte is completely irrelevant and unchanging in all cases, BE or LE. bit order is only considered for convenience of writing numbers down somewhere, CPUs never reverse the bit order unless explicitly told to do so. The byte is most commonly considered as an immutable unit. So writing [15..8] or [8..15] are the same thing as far as endian is concerned.
Post 28 Dec 2009, 02:58
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: 17271
Location: In your JS exploiting you and your system
revolution
sinsi wrote:
Maybe intel should make their next cpu's bi-endian Smile
Then we can see who wins...
ARM is "bi-endian". I have yet to see anyone that uses it in BE mode. There may be some that do use it in BE mode, but it is not common.
Post 28 Dec 2009, 03:00
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
sinsi wrote:
Maybe intel should make their next cpu's bi-endian Smile
Then we can see who wins...


Ever mess with the ISO format for cdroms?

Quote:
bswap is not broken. It does what it was designed to do, swap bytes.


Point made, then. Wink

Quote:
bit order within a byte is completely irrelevant and unchanging in all cases, BE or LE. bit order is only considered for convenience of writing numbers down somewhere, CPUs never reverse the bit order unless explicitly told to do so. The byte is most commonly considered as an immutable unit. So writing [15..8] or [8..15] are the same thing as far as endian is concerned.


My point said, or were you trying to say this implictly and i misinterpreted? Embarassed

Quote:
ARM is "bi-endian". I have yet to see anyone that uses it in BE mode. There may be some that do use it in BE mode, but it is not common.


Is there any known performance difference between the two modes?
Post 28 Dec 2009, 03:47
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
>Ever mess with the ISO format for cdroms?
Reading is easy, writing is slightly harder, but still easy.
Post 28 Dec 2009, 03:51
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
kohlrak wrote:
Is there any known performance difference between the two modes?
In hardware it is simply two xor gates on the A0 and A1 address lines. But in software that uses bignums there is a very large difference in what code has to written. The BE code is a lot longer and more complex. Embedded systems usually can't afford the extra code for BE.
Post 28 Dec 2009, 04:00
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:
In hardware it is simply two xor gates on the A0 and A1 address lines. But in software that uses bignums there is a very large difference in what code has to written. The BE code is a lot longer and more complex. Embedded systems usually can't afford the extra code for BE.


I've heard this earlier, but i can't see how it could be. However, i've never really worked with "bignums" before, so i can't really offer a counter argument. Personally, if i needed something bigger than the bus width, i'd end up making a simple CAS (more accurate too, since it dosn't really use numbers, but emulates them via strings [allowing you to simplify using NaNs and such], but the problem is that it's incredibly slow and memory intensive).
Post 28 Dec 2009, 05:16
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
that's because big-endian has to go backwards, so a bignum would have to be stored from highest address to lowest address, or in other words, if you viewed it with a hex editor which displays the address from lowest (like just about any out there) you would see the number backwards. If that is the case, it's the same efficiency as little endian, except that most CPU addresses even in big endian load words with INCREASING addresses, not decreasing...


and I really have no idea what you are babbling about the bit order, no one said the bits are reversed as well, which is why I precisely was arguing about the 'shifting'. We don't know the order of the "bits", we don't know whether big endian or little endian are more 'correct' in the bit-order, seeing as we can label them either 0...7 or 7...0 and it won't change a god damn thing. So I really don't see your point with it, when I precisely argued about the shifting for this exact thing.

In fact, if you reverse the bit order in your head, everything would be perfectly fine no matter how you put it, except for shifting/rotating where "right" would be 'left' and "left" would be 'right', or if you imagine them in a circle, then whatever direction it is (generally, if shift was renamed to "shift to lower" and "shift to higher" then this naming problem would disappear)

I don't know what you don't understand from this, are you playing dumb on purpose? Cause I know you aren't dumb.
Post 28 Dec 2009, 22:13
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
Quote:

that's because big-endian has to go backwards, so a bignum would have to be stored from highest address to lowest address, or in other words, if you viewed it with a hex editor which displays the address from lowest (like just about any out there) you would see the number backwards. If that is the case, it's the same efficiency as little endian, except that most CPU addresses even in big endian load words with INCREASING addresses, not decreasing...

Well, perhaps under some circumstances you'll need to strictly follow big-endian ordering at bignum level, but why not just no go farther than machine word level and then keep words ordering in little-endian?

Example of 128-bit num:
<[31-24][23-16][15-8][7-0]><[63-56][55-48][47-40][39-32]><[95-88][87-80][79-72][71-64]><[127-120][119-112][111-104][103-96]>

It has a portability problem of course, if I upgrade the code to 64-bit, then I won't be able to add with 64-bit operands until I update the data structure to use 64-bit machine words (with little-endian this problem wouldn't happen).

revolution, do you have some specifics about why using bignums in ARM with BE mode enabled is harder?

I'm still not having clear in my head how this is at bit level, but considering the way you said ARM implements the modes I guess then than one of those mode won't have bit 7 and 8 side by side.
Post 29 Dec 2009, 01:52
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
LocoDelAssembly, the problem is access to individual bytes within the words. Plus the counters are reversed and causes confusion (and bugs) for the programmers. You have to pre-decrement all addresses based upon system bus width when doing access, not many programmers are familiar with it and C seems to not understand that it is even possible without much programmer help. When storing and passing addresses to the OS you need the base address not the last address, but when doing basic computations (except divide) you have to start at the last address (with pre-decrement based upon system bus width) and work backwards, terminating on first-address-minus-system-bus-width.

Memory reallocation is problematic, the OSes all work with base addresses and extending numbers as they grow requires extra code to keep the BE numbers in proper order. Many programmers feel compelled to use a mixed setup with words in LE (and the bytes in BE as enforced by hardware) to solve the memory problem but that creates a huge headache for systems with different basic storage sizes (16bit vs 32bit vs 64bit)
Post 29 Dec 2009, 02:33
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

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

< 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.