One unified OS for the future?

[biggun]

A cross platform (and endianess) program can access memory with either big endian or little endian but only a byte at a time without byte order swapping. Without hardware byte swapping, cross platform (and endianess) programs can run significantly slower than endian specific programs that work with 4 bytes at a time using a 32 bit CPU.

Since ages (since the 486) the x86 support single instruction 32bit byte swapping to process Big Endian data.

[guest11527]

The hardware choice plays a factor on how easy it is to move on. Moving to little endian hardware means updating old code which can be a big task depending on the software.

Actually, no. Introducing a sandbox is necessary anyhow, unless you are willing to carry on with the AmigaOs un-protected memory access. You would be ill-adviced if so. Once you have a sandbox, there is no necessary relation between legacy structures used with a 68K emulation sandbox and the structures of the outside Os, and if you have to emulate 68K - believe me - the endian swap is your least problem. xUAE isn't slow because of the endian swap. It is slow because it tries to emulate all features of the hardware for those applications that bypass the Os.  

 The 68k Amiga is easier and more fun to use and program anyway.

Like I already said, there are two options: Option one is to modernize the hardware completely and go for a software only company. In that case, hardware is irrelevant and good hardware is available cheaply in the x64 camp. Endianness is then your least worry. If you want to take the Amiga legacy seriously - and this is the second path - then PPC, ARM and x64 are all equally unsuitable in first place. You would then need a hardware emulation(!) of the 68K and the custom chips, and probably carefully extend that with some emulation of expansion boards (like P96 for graphics). This was the idea with Natami, and the FPGA emulation. It is also an option, but goes into a different direction, namely the retro market.

Strangely enough, none of these options have been picked up by the big players.

[biggun]

If you want to take the Amiga legacy seriously - and this is the second path - then PPC, ARM and x64 are all equally unsuitable in first place. You would then need a hardware emulation(!) of the 68K and the custom chips, and probably carefully extend that with some emulation of expansion boards (like P96 for graphics). This was the idea with Natami, and the FPGA emulation. It is also an option, but goes into a different direction, namely the retro market.

Strangely enough, none of these options have been picked up by the big players.

With todays low cost FPGA you can instantiate a compatible chipset able to display FullHD
and you can instantiate an 68K core faster than 68060,  
speed wise in the range of lower PPC systems.

Maybe people want more speed than a FPGA-68K equal low end PPC would provide?

[utri007]

Amiga Os would need a investor and losts of money. In current form it doesn't matter wich CPU architehture it uses, as there is no resources to port OS to any other cpu.

With money would wouldn't matter because it is perfectly possible to produce low cost / powerfull hardware with PPC cpu. It would require at least 10 000 - 15 000 mobos minium to get production cost low as 20-50€/mobo.

Amiga OS has a choosed to use "Amiga hardware", wich is nice choise, at least hardware collector point of view.

What I don't understand is that some people seems to belive that x86/ARM would some how make a Amiga OS more viable for general use. That is not a true.

RiscOS what happened to userbase when 20€ hardware came availlable?
BeOS devs blame x86 for dead of BeOS, no more decicated users.
Typical life cycle of x86 mobo is 1-2 months, one production run and then good buy.

[biggun]

With money would wouldn't matter because it is perfectly possible to produce low cost / powerfull hardware with PPC cpu. It would require at least 10 000 - 15 000 mobos minium .

Well if you produce that many than there would be the funds
to also produce 68k cores which can compete with PPC systems.
Including real AMIGA chipsets again.

Right now we can with FPGA technology build 68k system
in the performance range of PowerpC Efika systems.

If you would produce around 15,000 - 20,000 systems as you describe
then you could "bake" real 68Ks including AMIGA chipset as SOC.

These systems would have the real chipset and performance
wise would be able to play in the same league as PowerPC AMIGA XE systems.

[guest11527]

Amiga Os would need a investor and losts of money. In current form it doesn't matter wich CPU architehture it uses, as there is no resources to port OS to any other cpu.

There might be resources in the community, but the current development form is not very attractive for developers. Essentially, you get only a small userbase, and you have to pay $$$ for a development platform offering no return of investment.  

What I don't understand is that some people seems to belive that x86/ARM would some how make a Amiga OS more viable for general use. That is not a true.

No, of course that's not true. Whether AmigaOs runs on x86 or PPC does not impact its usability or usefulness. But it would allow developers to join cheaply by using hardware that is available, and it wouldn't require potential users to make a huge investment into outdated hardware you cannot use for anything. The current hardware is "special" because it is exotic, but it is not "outstanding" in terms of performance. It can be replaced by PC hardware without loosing essential features.

[wawrzon]

so this is an interesting and informative discussion out of the sudden?
funny enough i cant find anything new here. ive heard all these arguments over and over and everybody knows that its just talk. no action will follow and nothing will be influenced by this thread. its just what they call a valve to set some hot air that people gathered free and proceed as previous.

[zylesea]

I thought this discussion was about the (impossibility) possibility of a single OS that could unify the Amiga community, not the pros and cons of which hardware to use for any OS?  What ever, carry on........ but some of these statements are seeming fairly useless to me.  I hope we are not creeping back toward any kind of discussion that start pointing fingers and claiming which choices are the RIGHT choices, and everything else is the wrong choice.

Actually the hardware does matter. I think at least MorphOS and OS4 have a similar status quo, but a different long time strategy. AFAIU OS4 wants to stay on ppc and keep compatible to its current incarnation while bringing SMP and stuff like that to the OS. And while I doubt feasability of that approach it actually is their approch. MorphOS evolves and matures a little more in its curent incaranation on ppc but then, eventually, will do a sharp cut to a "MorphOS NG" with SMP, 64 Bit, full resource tracking, and maybe - maybe not - full MP. But this will come at the cost of direct compability. And that sharp cut will come with an ISA switch, too. Either to x64 (_my_ preference) or to ARM. AFAIK the ISA is not yet set into stone. If resources were huge, support for several ISAs for MorphOS NG would be also possible (but resorces aren't huge, hence it's only theory).
AROS (x86) kind of switched ISA (well AROS is available for many ISAs) already for the cost of binary compability while keeping API compability - with the disadvantage that SMP or MP are not present in AROS as they aren't in  OS4 or MorphOS today. Introducing SMP or MP to AROS would mess things up there as much as it messes things up in MorphOS or OS4.

[OlafS3]

Actually the hardware does matter. I think at least MorphOS and OS4 have a similar status quo, but a different long time strategy. AFAIU OS4 wants to stay on ppc and keep compatible to its current incarnation while bringing SMP and stuff like that to the OS. And while I doubt feasability of that approach it actually is their approch. MorphOS evolves and matures a little more in its curent incaranation on ppc but then, eventually, will do a sharp cut to a "MorphOS NG" with SMP, 64 Bit, full resource tracking, and maybe - maybe not - full MP. But this will come at the cost of direct compability. And that sharp cut will come with an ISA switch, too. Either to x64 (_my_ preference) or to ARM. AFAIK the ISA is not yet set into stone. If resources were huge, support for several ISAs for MorphOS NG would be also possible (but resorces aren't huge, hence it's only theory).
AROS (x86) kind of switched ISA (well AROS is available for many ISAs) already for the cost of binary compability while keeping API compability - with the disadvantage that SMP or MP are not present in AROS as they aren't in  OS4 or MorphOS today. Introducing SMP or MP to AROS would mess things up there as much as it messes things up in MorphOS or OS4.

Would it be possible at all to develop a "modern" amiga-based OS without sacrificing not only binary but also source compatibility? If everything would have to be broken what sense would that make at all? And what software could then run on it (except 68k in UAE)?

[wawrzon]

Would it be possible at all to develop a "modern" amiga-based OS without sacrificing not only binary but also source compatibility? If everything would have to be broken what sense would that make at all? And what software could then run on it (except 68k in UAE)?

exactly. if you have to sandbox 68kand start over from the very beginning, why try to create another os at all? what unique concepts of amiga could be reimplemented in that os, that wouldnt be present in another modern os or couldnt be derived from some linux distribution?

correct me if i am wrong, but i guess: none.

there is two edge cases here. aros may make sense as far as it carries over some amiga balast like unified memory space or messaging by passing pointers (?), but anything that would attempt to make it more modern in underlying sense, might make it non-sense in general. so the one and only future proof version of amiga is a 68k sandbox on whatever system of your choice.

[matthey]

Since ages (since the 486) the x86 support single instruction 32bit byte swapping to process Big Endian data.

A CISC CPU can do an operation instead of a BYTESWAP if the endianess is the same. The x86 BSWAP is to a register only so there is 1 additional instructional and an extra 4 bytes per memory access. CISC can normally do:

Code: [Select]

  OP.L mem,Rn
   OP.L Rn,mem

with the x86 BSWAP instruction and memory using the wrong endianness this becomes:

Code: [Select]

  MOV.L mem,Rn
   BSWAP Rn
   OP.L Rn
   OP.L Rn
   BSWAP Rn
   MOV.L Rn,mem

RISC may not have any other penalty beyond their load/store penalty. However, both PPC and ARM have disadvantages when in their non-native endian mode. It's not optimal to have memory in the opposite endianess of data needs.

Actually, no. Introducing a sandbox is necessary anyhow, unless you are willing to carry on with the AmigaOs un-protected memory access. You would be ill-adviced if so. Once you have a sandbox, there is no necessary relation between legacy structures used with a 68K emulation sandbox and the structures of the outside Os, and if you have to emulate 68K - believe me - the endian swap is your least problem. xUAE isn't slow because of the endian swap. It is slow because it tries to emulate all features of the hardware for those applications that bypass the Os.

Partial memory protection is possible on the Amiga without compatibility problems and without a sandbox. Shared memory for message passing and AmigaOS structures has as many advantages as disadvantages so I would keep it. Programs should protect private data and code with memory protection using a common API including new protection flags in executable formats like Amiga hunk or ELF.

[paolone]

exactly. if you have to sandbox 68kand start over from the very beginning, why try to create another os at all? what unique concepts of amiga could be reimplemented in that os, that wouldnt be present in another modern os or couldnt be derived from some linux distribution?

correct me if i am wrong, but i guess: none

Happy to correct you: datatypes, assigns, user interface.

My receipt would be quite simple (actual cooking wouldn't). Take FreeBSD (or Linux, but I personally prefer BSD licensing model, than GPL), keep everything except UNIXoid file structure and add Amiga volume/device names, assign, datatype system, MUI, then port from AROS missing components like intuition, amiga shell commands, DirectoryOpus 5 and/or Wanderer, or straightly Ambient from MorphOS. You'll end up with a modern operating system, on-par with MacOS X, with Amiga user interface.

Yes, it wouldn't be compatible with sources, but you can host AROS for them.

Yes, it wouldn't be compatibile with binaries, but you can port UAE for them.

Yes, it wouldn't be an AmigaOS-like system anymore, but if you want a MODERN "Amiga like experience" then you have to deal with a MODERN operating system and no, you do not need to reinvent the wheel again, even Apple didn't with MacOS X. Please bring me a Mac user that would now turn back to OS Classic, please.

[zylesea]

Would it be possible at all to develop a "modern" amiga-based OS without sacrificing not only binary but also source compatibility? If everything would have to be broken what sense would that make at all? And what software could then run on it (except 68k in UAE)?

A sandbox alone cannot overcome all shortages.

If API stays as similar as possibie recompilation should be done with rather little effort. Part of it is that I _myself_ still put MP for a next generation OS still in question. An NG (Amigaish) OS doesn't need to run nuclear power plants, hence I guess MP could still be left out. Would ease up many things (API could keep pretty similar) and staying as snappy as it is now should be easier too. On _my_ priority list for a NG OS SMP and 64 bit are pretty important, full resource tracking very welcome. MP would be nice, but only if "cost" isn't too high. Needs careful selection of trusted software though (pretty much as it is on Amiga today).

[biggun]

My perfect OS

* does not need to have 64bit pointers.

* does not need to have memory protection

* does not need to support many cores.


I actually think that AMIGA OS as it was and is -
actually is quite what I'm looking for. :-)

[wawrzon]

Happy to correct you: datatypes, assigns, user interface.

doesnt sound like much.


biggest problems seems the linux-oid  file structure as you yourself notice.

certainly if there is no valid replacement for assign, such a program could be done after the previous problem has been solved.

with the interface you likely mean workbench. well, actually all contemporary guis share similar philosophy introduced by xerox, mac and amiga. they are bloated, as amiga would become if it survived, but bloated with additional and sometimes unnecessary functionality. actually aros wanderer strives to catch up with any of them as well as the genuine workbench, and this demonstrates the woes of reimplementation pretty well i guess.

and datatypes.. isnt there a similar system in any of the contemporary oses? libreries to open certain file formats? im not sure but i would expect that.. in fact the genuine amiga systems had another annoying flaw to open files with application stored in tooltypes, which could not be changed once for all if the host system was lacking the particular app, but had an alternative named or located elsewhere.

[Blinx123]

@wawrzon

If by "file structure" you're referring to the Linux file system hierarchy: It can be worked around (and in fact has been in the past. By the LinuxStep project).

Possibly the easiest solution is doing what Apple did inside Mac OS X. Adding symbolic links and hiding part of the hierarchy.