#6 Quote:

In case this might affect your thinking: Quote: X5000 and Cyrus+ have recently dissappeared from the product selection of AmigaKit. Source discussion You might also notice there is no version of AmigaOS offered on that same site. For that matter I don't even see "Hyperion" in the lengthy manufacturer list.

The X5000 may be sold out rather than a removal of "AmigaOne" labeled hardware from AmigaKit. The avoidance of "AmigaOne" labeled hardware must be what is keeping the AmigaOne 1222 from market too.

The exclusion of Hyperion and AmigaOS from AmigaKit are more likely signs of action but why? The 2009 settlement agreement shall "remain in force until such time as a court of competent jurisdiction has issued a final and non-appealable ruling on the existence of a material breach justifying termination of this Agreement". The agreement is terminated at the time of a non-appealable final court ruling and *not* at the time of the "material breach". One exception would be if the 2009 settlement agreement was declared void at inception for lack of quid pro quo or because of coercion but it doesn't look like the Amiga parties have pursued these arguments. Were the removals of Hyperion and AmigaOS from AmigaKit actions as part of the cancelled new settlement agreement or just CYA?

@matthey

Quote:

The avoidance of "AmigaOne" labeled hardware must be what is keeping the AmigaOne 1222 from market too.

I can think of many reasons seriously.

But the least sinister is the worldwide parts shortage that even huge companies can not address.

Added: I also mentioned something else
here

#6

Last edited by number6 on 23-Apr-2021 at 07:58 PM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@michalsc

Quote:

More then you think. The most common case is working with binary data of any form. Imagine some simple check of a header of some binary file: if (data8[0] == 'E' && data8[1] == 'L' && data8[2] == 'F')

I don't understand. This code is endianess safe no matter if compiler optimizes it into 32 bit check or not.

@Georg

Quote:

I don't understand. This code is endianess safe no matter if compiler optimizes it into 32 bit check or not.

Sorry, I should have put myself more clear here. What I have meant is an endianness issue in general. We had discussions on AW.net as well as in other places where ppl were trying to argue that endianness is not an issue because one could just swap every fetch of data on cpu with the "other" endianness and that way solve endianness issues on an operating system.

What I was trying to show here is that this is not the case due to compiler optimisations discarding the size of underlying data types.

Sorry for previous explanation which was too short to clarify myself :)

@michalsc

Quote:

ppl were trying to argue that endianness is not an issue because one could just swap every fetch of data on cpu with the "other" endianness and that way solve endianness issues on an operating system

If "one" == the C compiler then they are right. There's an big endian x86 OS (Stratus VOS) which does that. If the compiler backend correctly ~fools the compiler into seeing the x86 as big endian, it should not cause compiler optimisations to break things.

@Georg

Quote:

If "one" == the C compiler then they are right.

Indeed. But if the compiler is not available and the binary is already compiled then it will be only partially possible (e.g. running m68k BE binaries on x86 LE Aros in the same was as Petunia or Trance does it)

@Trixie

Well, we mentioned X5000 and AmigaOS being gone from the site, so...

need to see if this falls in the same category

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@michalsc and @simplex

Hi there!

I just stumbled onto these blog posts (via Hacker News), very interesting explanations and discussions of endianness!

- The Byte Order Fiasco
- The byte order fallacy

Cheers!

_________________
Tygre
Scientific Progress Goes Boing!

@tygre

Thanks; that's very interesting.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

#6 Quote:

Well, we mentioned X5000 and AmigaOS being gone from the site, so...

This wouldn't be the first time A-Eon/AmigaKit were "busy" and difficult to contact. I can't imagine that supporting their existing AmigaOne customers could be a legal liability due to the current lawsuit. My comment about the 1222 delays above was a sarcastic joke by the way.

tygre Quote:

I just stumbled onto these blog posts (via Hacker News), very interesting explanations and discussions of endianness! - The Byte Order Fiasco

There are some good points but using octal shift counts and decimal masks are cringe worthy instead of "elegant". The poorly chosen octal designation character in C doesn't help but neither does the rare use of octal any more. In my opinion, it's usually better to use decimal shift counts and hexadecimal masks for readability.

tygre Quote:

- The byte order fallacy

It is unclear if there is a problem "The Byte Order Fiasco" is trying to avoid by recommending all unsigned values when shifting. It could be clearer that i is an unsigned integer even though the "data stream has a little-endian-encoded 32-bit integer". The code relies on the compiler recognizing a pattern and converting it into one 32 bit load or it will do 4 byte loads with shifts and or instructions. There are multiple variations of this code the compiler has to recognize which some compilers will not be able to do especially older ones which are commonly used for the Amiga. Better disassemble your executable to make sure the code is using a single load but then it helps to have more readable assembler code like the 68k. While it is portable because it reads bytes at a time, it is dependent on compilers recognizing code patterns to make it optimal. If the code is not recognized then it is more optimal to use the GCCism __builtin_bswap32(). I wrote a universal link library for compilers which don't support it like vbcc although there were only 137 downloads which is not enough users to even properly test it.

http://eab.abime.net/showthread.php?t=82114

Big endian code is more human friendly. Bytes appear sequentially in memory in the order they are used making text and numbers easier to read when debugging. It is also easier to change programs to use different data sizes. For example, let's say we are loading 32 bits at a time and then change the program to load 64 bits at a time. The order of the data doesn't change with big endian. Little endian requires knowing the sizes of all data accesses and reordering the data appropriately if they change. Little endian made sense when fetching the least significant bytes was important for multi-precision integer math of data in memory with no caches but those days are long gone. It looked like big endian would win at one point but little endian has come back now and big endian is now near extinction. Fewer and fewer software and hardware developers are caring about supporting big endian. This is not good for the Amiga unless deciding to break compatibility and create a little endian Amiga which AROS has tried with no noticeable gain in market share.

Last edited by matthey on 11-May-2021 at 12:42 AM.
Last edited by matthey on 11-May-2021 at 12:41 AM.

@matthey

Quote:

This wouldn't be the first time A-Eon/AmigaKit were "busy" and difficult to contact.

Sorry, I don't undertand that connection to what I said.

I was replying to Trixie about 3 things missing from the site. The X5000 h/w listing. Any and all versions of AmigaOS. And absence of Hyperion from their "Manufacturer" list.

Since then arose the inability to get a response about the 3 versions of uboot being used on said h/w, which were also linked to.

This includes the Mark Olsen approved version "U-Boot molsen-2018-10-05", which would be the current "fixed" version. This version is not offered nor was a response obtained on how someone without this version could acquire it.

Considering I also linked to the post about Hyperion cancelling their classic contract, all of the above also smells of a cancelled contract. Feel free to disagree.

#6

Last edited by number6 on 11-May-2021 at 01:29 AM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@tygre

That was interesting. Sorry to carry this thread further off course, but from the first link, does anyone know anything about this?

Quote:

John von Neumman's design doc from the second world war for EDVAC, which very clearly laid out that the plan was to have 32-bit little endian two's complement integers.

_________________
"Unix is supposed to fix that." -- Jay Miner

@bison

He's probably referring to this document, where Von Neumann suggests building an adder in such a way that one proceeds from least significant bit to highest, for obvious reasons. See section 5.2, for example. But Von Neumann also gives a reason for this which simply doesn't apply to microprocessors, Quote:

[T]he digits appear in a temporal succession and not simultaneously, cf. 7.1. The details are most simply evident in the discussion of the adder in 7.2.

In a microprocessor, the bits appear simultaneously in the unit, so unless he means something else, he's badly misreading Von Neumann on endianness.

That aside, I've found several websites that agree Von Neumann intended two's complement, but none of them breathe a word on his preferences for endianness, another reason I suspect the author had misread VN.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

#6 Quote:

I was replying to Trixie about 3 things missing from the site. The X5000 h/w listing. Any and all versions of AmigaOS. And absence of Hyperion from their "Manufacturer" list. Since then arose the inability to get a response about the 3 versions of uboot being used on said h/w, which were also linked to. This includes the Mark Olsen approved version "U-Boot molsen-2018-10-05", which would be the current "fixed" version. This version is not offered nor was a response obtained on how someone without this version could acquire it. Considering I also linked to the post about Hyperion cancelling their classic contract, all of the above also smells of a cancelled contract. Feel free to disagree.

Maybe but don't you think there are multiple contracts? The AmigaOS 4 classic contract may have expired already in 2021 so maybe no need to cancel it. I would think AmigaKit would still want to sell it though. I would expect uboot contracts would be worded in such a way that updates could still happen after contract expiration but we have seen some crazy Amiga related contracts. A-Eon/Amigakit could be delaying buying of Hyperion products to play it safe legally and be in a better relationship with Amiga Corporation in case they win the lawsuit. Maybe A-Eon/Amigakit and Amiga Corporation are keeping the new settlement agreement Hyperion backed out of. It does look like A-Eon/AmigaKit are shunning Hyperion products for whatever reason.

@simplex

Thanks for the link. I had found that document, but searched for the sequences "endian" and "32" and missed the section you mention.

RE temporal succession, see this:

https://stackoverflow.com/questions/13926760/the-reason-behind-endianness

Not everything said there is correct, but there is some interesting information nonetheless.

_________________
"Unix is supposed to fix that." -- Jay Miner

@number6

Re: Objection filed to "TheA500" trademark

Several days ago the trademark application was published once again.

Interesting...

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@matthey

Quote:

Big endian code is more human friendly. Bytes appear sequentially in memory in the order they are used making text and numbers easier to read when debugging. It is also easier to change programs to use different data sizes. For example, let's say we are loading 32 bits at a time and then change the program to load 64 bits at a time. The order of the data doesn't change with big endian. Little endian requires knowing the sizes of all data accesses and reordering the data appropriately if they change. Little endian made sense when fetching the least significant bytes was important for multi-precision integer math of data in memory with no caches but those days are long gone. It looked like big endian would win at one point but little endian has come back now and big endian is now near extinction. Fewer and fewer software and hardware developers are caring about supporting big endian. This is not good for the Amiga unless deciding to break compatibility and create a little endian Amiga which AROS has tried with no noticeable gain in market share.

Very interesting, thanks for the insights!

Cheers!

_________________
Tygre
Scientific Progress Goes Boing!

Can we all agree that the world is full of cunts regardless of their endienness.

_________________
Amiga A1200, 3.1 ROMs, Blizzard 1230 MKIV 64MB & FPU, 4GB DoM SSD, Workbench 3.1

@A1200

Quote:

A1200 wrote: Can we all agree that the world is full of cunts regardless of their endienness.

And like endianness, there are little and big c*nts

_________________
Tygre
Scientific Progress Goes Boing!

@tygre

plan 9 has memory protection and do not depend on sharing data like Amiga Os
so this explanations are worth nothing on amiga