Click Here
home features news forums classifieds faqs links search
6071 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
61 crawler(s) on-line.
 18 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 Mobileconnect:  55 mins ago
 Rob:  1 hr ago
 AndreasM:  1 hr ago
 Derfs:  1 hr 24 mins ago
 BigD:  1 hr 27 mins ago
 OlafS25:  1 hr 35 mins ago
 Frank:  1 hr 37 mins ago
 ppcamiga1:  1 hr 39 mins ago
 kamelito:  1 hr 58 mins ago
 pavlor:  2 hrs 3 mins ago

/  Forum Index
   /  Amiga Development
      /  interesting discussion about endianness.
Register To Post

Goto page ( Previous Page 1 | 2 )
PosterThread
Hypex 
Re: interesting discussion about endianness.
Posted on 9-Aug-2021 14:32:55
#21 ]
Elite Member
Joined: 6-May-2007
Posts: 10308
From: Greensborough, Australia

@ppcamiga1

My point in the examples is porting software to AmigaOS. Software that is written to be non-portable in a portable language. Some software is written to assume a specific byte order and such software will break if not fixed even after it managed to compile.

 Status: Offline
Profile     Report this post  
fishy_fis 
Re: interesting discussion about endianness.
Posted on 11-Aug-2021 15:07:47
#22 ]
Super Member
Joined: 29-Mar-2004
Posts: 1952
From: Australia

@ppcamiga1

Yes, "holy war" against ppc by AROS developers.
That's why there's a ppc version of AROS and why AROS developers have contributed toward ppc and 68k Amiga based systems.
Because of crusades and holy wars against ppc.

Have you stopped taking your meds?

 Status: Offline
Profile     Report this post  
tygre 
Re: interesting discussion about endianness.
Posted on 20-Aug-2021 22:36:25
#23 ]
Regular Member
Joined: 23-Mar-2011
Posts: 247
From: Montreal, QC, Canada

@ppcamiga1 @hypex

Although I like the example of 0xCAFEBABE

Here is a very interesting article on the (dis)advantages of Big vs. Little Endian with diverse criteria. At the end, it seems that Little Endian is more advantageous...

PS. I can't understand why some must bring some dubious "historical" figure in a technical discussion about Endianness! Let's stay on topic and technical!

Last edited by tygre on 20-Aug-2021 at 10:39 PM.
Last edited by tygre on 20-Aug-2021 at 10:37 PM.
Last edited by tygre on 20-Aug-2021 at 10:36 PM.

_________________
Tygre
Scientific Progress Goes Boing!

 Status: Offline
Profile     Report this post  
matthey 
Re: interesting discussion about endianness.
Posted on 21-Aug-2021 0:00:16
#24 ]
Super Member
Joined: 14-Mar-2007
Posts: 1230
From: Kansas

tygre Quote:

Here is a very interesting article on the (dis)advantages of Big vs. Little Endian with diverse criteria. At the end, it seems that Little Endian is more advantageous...


My reassessment of article assessment.

Big Endian Advantages
human readable (naturalness)
two's complement signed integer and floating point detect sign
searching/sorting unknown length datatypes (sorting unknown blobs)
network order (convention) and old order (68k, PPC, SPARC, MIPS, SuperH)
arbitrary precision integer division and floating point fetch and calc (mostly outdated advantage)

Little Endian Advantages
current most used order (x86, x86-64, ARM, RISC-V)
recasting a pointer
detect odd/even integer and floating point (less common than sign detect)
variable/arbitrary length encoding advantage (combined 2 similar categories)
arbitrary precision integer add and subtract fetch and calc (mostly outdated advantage)

Arbitrary precision addition and subtraction are *not* a problem with big endian (68k uses ADD+ADDX for example). There used to be a fetch advantage for what data was needed first but now larger datatypes, wider ALUs and caches have practically eliminated any advantages.

Last edited by matthey on 21-Aug-2021 at 12:21 AM.
Last edited by matthey on 21-Aug-2021 at 12:21 AM.

 Status: Offline
Profile     Report this post  
ppcamiga1 
Re: interesting discussion about endianness.
Posted on 22-Aug-2021 7:57:26
#25 ]
Regular Member
Joined: 23-Aug-2015
Posts: 366
From: Unknown

@tygre

Interesting article that has nothing to do with Amiga.
Most of Amiga software is big endian.
And expect data in os and other software in big endian format.
So Amiga was big endian, is big endian and will be big endian.

 Status: Offline
Profile     Report this post  
Hypex 
Re: interesting discussion about endianness.
Posted on 22-Aug-2021 8:01:15
#26 ]
Elite Member
Joined: 6-May-2007
Posts: 10308
From: Greensborough, Australia

@matthey

My take on this.

Quote:

Big Endian Advantages
human readable (naturalness)
two's complement signed integer and floating point detect sign
searching/sorting unknown length datatypes (sorting unknown blobs)
network order (convention) and old order (68k, PPC, SPARC, MIPS, SuperH)
arbitrary precision integer division and floating point fetch and calc (mostly outdated advantage)


In practical use it goes deeper than being human readable. It's also the code order. In a machine code dump it is exactly how the CPU will see it with WYSIWYG. This means text can be read and written directly. Magic bytes of any size can be read and written. Multi size vectors can be read and written. Binary data written by 32-bit CPU can be read in by 64-bit CPU. Such as two 32-bit words read in as one 64-bit word. Interoperable between different CPU word sizes.

Quote:

Little Endian Advantages
current most used order (x86, x86-64, ARM, RISC-V)
recasting a pointer
detect odd/even integer and floating point (less common than sign detect)
variable/arbitrary length encoding advantage (combined 2 similar categories)
arbitrary precision integer add and subtract fetch and calc (mostly outdated advantage)


Wins popularity contest. Becomes illogical when data such as R5G5B5 is forced to be split into reverse order which breaks bitfields. Recasting a pointer may help in ASM but don't see advantage in high level. Text and magic bytes cannot be directly read and written, with programmers doing strange operations looking for backward text, rather than writing readable portable code. Binary data written by 32-bit CPU cannot be read in by 64-bit CPU. Such as two 32-bit words cannot be read in as one 64-bit word. Not iteroperable between different CPU word sizes.

 Status: Offline
Profile     Report this post  
ppcamiga1 
Re: interesting discussion about endianness.
Posted on 22-Aug-2021 8:07:51
#27 ]
Regular Member
Joined: 23-Aug-2015
Posts: 366
From: Unknown

@fishy_fis

little almost no support for ppc vs many years of attack and lies about ppc.

fishy_fis have you stopped taking your meds?

 Status: Offline
Profile     Report this post  
fishy_fis 
Re: interesting discussion about endianness.
Posted on 22-Aug-2021 12:00:42
#28 ]
Super Member
Joined: 29-Mar-2004
Posts: 1952
From: Australia

@ppcamiga1

What attacks and lies about ppc?
Can you name a single one?
If its been going on for years there must be at least one you can name?

Also, AROS is open source, as you yourself mentioned. Anyone can contribute if interested.
If there's not many contributions specifically for ppc then that is due to a lack of people interested, not of of some imagined (in your head only) conspiracy against ppc.

There's also the fact that code in general has been reused by ppc focused OSes.
How is that not contributing?

And Im not the one spewing crap or constantly spouting delusions that only exist in my head.
That would be you.
Ergo the inquiry about whether or not youve been taking your meds.
Because you're carrying on like a froot loop.

 Status: Offline
Profile     Report this post  
michalsc 
Re: interesting discussion about endianness.
Posted on 22-Aug-2021 12:42:49
#29 ]
AROS Core Developer
Joined: 14-Jun-2005
Posts: 307
From: Germany

@fishy_fis

Please, do not feed that troll. For his trolling actions he is being regularly blocked on other forums, especially in Poland. I count days until it happens here, too ;)

 Status: Offline
Profile     Report this post  
tygre 
Re: interesting discussion about endianness.
Posted on 22-Aug-2021 17:13:40
#30 ]
Regular Member
Joined: 23-Mar-2011
Posts: 247
From: Montreal, QC, Canada

@Hypex @matthey

Thanks for your comments!

But when using "high level" programming language, Big vs. Little Endian should not matter, right? Even with C... the compiler should take care of it?

Big vs. Little Endian should matter only? when the code must deal encoding/decoding data following some protocols, which may be Big or Little Endian, shouldn't it?

_________________
Tygre
Scientific Progress Goes Boing!

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: interesting discussion about endianness.
Posted on 22-Aug-2021 18:03:17
#31 ]
Elite Member
Joined: 9-Jun-2004
Posts: 11921
From: Norway

@tygre

Quote:
Even with C... the compiler should take care of it?


it does not take care of it, that’s the problem, instead we use macros, lookup tables and inline assembler code, precompiler #if's and so on.

int is int as long as its in memory, and as long hardware use same endianness.
short is short as long as its in memory, and as long hardware use same endianness.

Some times you work on 32bit data, and you have ALPHA, RED, GREEN, BLUE store in 32bit data, now need to access the RED, but it depends on endianness, where it is in 32bit data. Some times its 16bit data, R 5bit G 6bit B 5bit – RRRRRGGG GGGBBBBBB – swapped and it becomes GGGBBBBB RRRRRGGG, a total mess, anyway lookup tables are useful hare, but its is pain in the ass.

It effects files, when you save, and load data as well.

Is there language that can solve it, yes you make swap class, in C++, however it not something you do, because your conversion most often needs to light wight.

If added support for beInt32, leint32 to C and C++ language it be most useful featured added to it, some of new stuff in C++11, C++12 will never be used, it's just more bloat.

Last edited by NutsAboutAmiga on 22-Aug-2021 at 06:36 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 06:28 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 06:26 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 06:24 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 06:17 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 06:16 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 06:11 PM.
Last edited by NutsAboutAmiga on 22-Aug-2021 at 06:11 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

 Status: Offline
Profile     Report this post  
ppcamiga1 
Re: interesting discussion about endianness.
Posted on 23-Aug-2021 12:46:25
#32 ]
Regular Member
Joined: 23-Aug-2015
Posts: 366
From: Unknown

@fishy_fis

You fishy_fis are the one that spewing crap or constantly spouting delusions that only exist in your fishy_fis head.

As for aros. aros for x86 was mistake.
aros x86 was not source and binary compatible with Amiga OS.
And at the same time this aros x86 has not memory protection.
Nobody need this crap.

aros devs should start from 68k or ppc version.
From something with integration with 68k Amiga software.
Made good open source reimplementaion of Amiga gui and graphics.
Then swithc to unix.



 Status: Offline
Profile     Report this post  
ppcamiga1 
Re: interesting discussion about endianness.
Posted on 23-Aug-2021 12:47:50
#33 ]
Regular Member
Joined: 23-Aug-2015
Posts: 366
From: Unknown

@tygre

Big vs. Little Endian should matter only?
It is most important thing in making software for Amiga.

 Status: Offline
Profile     Report this post  
Hypex 
Re: interesting discussion about endianness.
Posted on 27-Aug-2021 9:53:41
#34 ]
Elite Member
Joined: 6-May-2007
Posts: 10308
From: Greensborough, Australia

@tygre

Quote:
But when using "high level" programming language, Big vs. Little Endian should not matter, right? Even with C... the compiler should take care of it?


Right, it shouldn't matter. The compiler should take care of it, in the case I was talking about, with making a recast.

And if code is isolated, such as it doesn't need to read in or export binary data, then endian wouldn't matter.

Even a magic ID, such as "TEXT" to give an example, can be encoded in 32 bits so that the compiler creates the proper byte order that works on any endian.

Quote:
Big vs. Little Endian should matter only? when the code must deal encoding/decoding data following some protocols, which may be Big or Little Endian, shouldn't it?


That's right. It tends to be with data structures. And files coded in little endian. And in cases where the coder didn't write proper portable code and assumed specific byte order. Such an assumption goes deeper than high level coding and even if true in most cases, it's bad form to assume low level specifics when writing high level code, as well as not being portable.

Compilers tend to lack support for specifying data encoding which would help in a lot of cases. They can support built in conversions but it doesn't always help and doesn't always work. For example, GCC has a built in endian swap, but it's useless on PPC because it can't swap inside a register, unlike x86. But, it can do it when reading/writing to memory, which is where it's most important. However, GCC is designed to do it from a value, not a pointer so the operation suffers on PPC.

And so, it makes it hard to deal with it and unless the code is written to deal with it, by using macros for every read or write that can also be annoying, then needing to fix code to be endian aware or agnostic can be a ton of work.

Last edited by Hypex on 27-Aug-2021 at 09:58 AM.

 Status: Offline
Profile     Report this post  
Goto page ( Previous Page 1 | 2 )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle