@kolla

What about Atari TOS for Mac 68K (via Shapeshifter)?

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

No idea, but EmuTOS is AFAIK actively developed... not that I use it.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

cdimauro Quote:

This is one of the other big mistakes of the Amiga o.s. developers: they should have aligned the library call entries to 64-bit size / 8-bytes to favor faster access to 32-bit processors and the ones with data caches. The whole Amiga platform, both hardware and software sides, seems to be affected by the "16 bits ought to be enough for anybody" mantra...

Hind sight should be 20/20 but the situation needs more historical examination from the time the Amiga was created. There were severe resource limitations at the time the Amiga was created to be more dynamic than any personal computer up to that time. The dynamic design and flexibility of the Amiga can be seen in the 68k CPU choice which allowed for 32 bit pointers, a flat memory model and address 4 being the only fixed address in the Amiga. The copper and blitter are significantly more flexible than earlier designs and were copied in newer hardware. The Amiga developers could have used a 68020, more memory, VRAM (dual ported memory) for gfx and new custom processes for chip fabrication allowing for more transistors but the result would have been more like a more modern and expensive Apple Lisa than a computer for the masses.

Not all the Amiga structures use natural alignment for datatypes either. The 32 bit 68020 was released in 1984 before the Amiga was released so the developers should have known better. Even the 32 bit registers in the 68000 should have been enough of a clue to naturally align all 32 bit datatypes. It doesn't require much CPU hardware knowledge to see this today but many of the Amiga software developers likely came from programming 8 bit computers with no caches. Still, the extra cycle here and there necessary for accessing unaligned data on the 68020+ is partially made up for by more compact data using less of the DCache. The same is true for the jump tables which are unaligned code using less of the ICache. The variable length instruction set of the 68k allows more compact code and better ICache efficiency usually giving better performance than less than optimal alignment would indicate. Branch targets in 68k code were and are rarely 4 byte aligned even on the 68020 where my Cape manual claims a ~5% performance improvement for 1-2% code enlargement. While I too would prefer 8 byte jump table entries today, the original Amiga was planned to have 256kiB of memory which may have left less than 100kiB free after boot and larger jump tables for all libraries would have taken a few more kiB of this away. Let's not forget how early the Amiga was before we accuse the Amiga developers of mistakes.

cdimauro Quote:

AROS has a 64-bit flavor and also MorphOS seems to being ported to x64, but I have no idea about how they implemented library calls. Keeping the 6 bytes convention they might: - load an offset to a register; - do a short jump to some (common) library's code which is near the library header; - finally, the common code takes the offset, calculates the real address to jump to, and then makes the final jump. But it's just an idea.

AROS x86-64 has no backward compatibility to worry about. Michalsc tells us how foreign architecture AROS jump table entries are formatted which if I understand correctly would resemble something like the following on the 68k.

move.l (-32,a6),a0 ; get data from -32 offset of jump table
jsr (a0) ; call library function

jsr ([-32,a6]) ; similar code as above using double memory indirect (same code size but saves a reg)

The code is 6 bytes for every function call instead of 4 bytes for jsr (-32,a6) as existing Amiga libraries currently use. It is better to use larger code in the jump table which is shared than enlarge all function call code. Even the 68060 can reduce the cost of a jmp xxx.l in the jump table to 0 cycles folding the branch away so there isn't much of a performance problem albeit less than efficient ICache used for jump table entries and branch cache entries used. With 6 bytes of overhead per function call, we could use the following code.

jsr xxx.l

The 68060 can execute the code in 1 cycle when the address is in the branch cache (return address needs to be pushed onto the stack so not 0 cycles). The libraries to open could be specified in the executable and the absolute addresses of function calls could be updated with proper addresses much like is done for a RELOC. On program termination, the libraries would be closed. Support could be added to the existing AmigaOS and would reduce function call overhead to a bare minimum (1 cycle jsr+ 7 cycle rts as 68060 has no hardware link/return stack but ColdFire v4 has a 2 cycle rts). The scratch register needed for the AROS 32 bit method is also saved although some RISC architectures do not have absolute addressing. While this method is nearly optimal for 32 bit addressing, it is less than optimal for 64 bit addressing as jsr xxx.q becomes 10 bytes for each function call because the 64 bit absolute addressing uses 8 bytes for the address. Absolute addressing is best avoided for 64 bit addressing and position independent code using PC relative references is more desirable.

It is possible to combine the library structure and table with the library code. The big advantage is that the whole library can be addressed with PC relative addressing and the a6 and a4 registers are freed as they are no longer needed as pointers. The disadvantage is that the library can't be used from ROM. Of course ROM has been replaced by NAND flash memory today. The disadvantages of NAND flash memory has been that it is lower performance than DRAM and that it has a limited number of read/write cycles but performance has improved over time and the read/write cycles have increased from 100,000 to 100 million for some types.

cdimauro Quote:

True: Amiga libraries are very nice, simple, and efficient solutions to share code. Nowadays I would have preferred a slightly but more efficient mechanism: replacing a library call with a JSR/CALL to an absolute address (for 32-bits code; to a RIP relative offset for 64-bit systems), to avoid the double jumps (or some stub code).

Yes, 32 bit addressing is easy as absolute addressing is efficient. Just need to lock the libraries of function calls into memory by having the loader open them as I have described above and then adjust the absolute addressing addresses to the final destination function entry points. I don't see how the RIP relative addressing, which uses a 32 bit register (max PC relative offset), allows to use the whole 64 bit address space. Even with virtual addressing to map libraries within 32 bit addressing distance (~4GiB) this seems rather limiting for a fully dynamic 64 bit OS with executables which are several GiB in some cases today. Could you please give some specifics of how you would make this work?

cdimauro Quote:

That's a big problem, because it requires either a PMMU (which you don't like) or duplicating the library header + jump table each time that a library is opened by a task/thread/process.

The MMU is a valuable tool. Just because I recognize the significant overhead of virtual addressing and process isolation does not mean I don't like it. I would prefer to have an Amiga with a MMU and for the AmigaOS to optionally support the MMU to improve reliability. I recognize that the current generation of AmigaOS can't have full process isolation but it can have partial memory protection provided with the MMU likely with a lower overhead compared to full and having the advantage of providing this optionally to conserve resources and improve responsiveness where it is too expensive. Such a 64 bit Amiga would need a different approach than trying to remap addresses closer together using virtual memory which has overhead and is pretty limiting with 32 bit RIP relative addressing anyway.

cdimauro Quote:

As usual, in the Amiga land: very short vision. They've just gone for quick (and often dirty) solutions to the problems which suddenly popped-up during the development...

Most of the Amiga solutions were simple and needed to be simple when the Amiga was developed. Mistakes were made and large gaps without significant development occurred. The same could be said of the 68k but we have to remember the 68000 was released in 1979 and the Amiga in 1985. What other personal computer from the 1980s is as flexible and dynamic as the Amiga? What other computer from the 1980s can adapt to appear as modern and easy to use as the Amiga while retaining good compatibility, a tiny footprint and a responsive GUI down to a 1 DMIPS CPU?

Last edited by matthey on 29-Sep-2021 at 01:37 AM.

@matthey

Quote:

matthey wrote: Hind sight should be 20/20 but ........ Most of the Amiga solutions were simple and needed to be simple when the Amiga was developed. Mistakes were made and large gaps without significant development occurred. The same could be said of the 68k but we have to remember the 68000 was released in 1979 and the Amiga in 1985. What other personal computer from the 1980s is as flexible and dynamic as the Amiga? What other computer from the 1980s can adapt to appear as modern and easy to use as the Amiga while retaining good compatibility, a tiny footprint and a responsive GUI down to a 1 DMIPS CPU?

I don't pretend to know anything about OS design, or how exactly the hardware of our Amiga computers work, but I do have a rudimentary understanding of each. Given all of the hindsight that 36 years of use has given our community, and the obvious talent that many Amiga users have. I have to wonder why a better OS for the Classic Amiga hardware has never been created. I'm talking about an OS that breaks backward compatibility with the original AmigaOS, but keeps all of the best things about it and improves upon them. I think that is what AROS should have been, instead of just trying to recreate or reverse engineer AmigaOS3.1, but I don't know enough about AROS to say exactly what it is, or if it does attempt to fix all of the short comings of AmigaOS3.1, but I'm pretty sure that it still has most of the limitations of AmigaOS3.1.

Regarding new PC hardware, now that hardware has become so many orders of magnitude faster than the 7MHz 68000 Classic Amigas and almost anything can emulate it, I think it would be great to see a new OS that has all the great ideas of the original AmigaOS, but none of its limitations, and it could have an Amiga emulator included with it to allow sandboxed backward compatibility. This is what I was hoping the MorphOS Dev. Team would create with their port to x64 hardware, but that does not appear to be what they are doing, from the initial proof of concept that has been demonstrated a couple of times in public.

Why don't we hear about new OSes being developed, or maybe I just don't visit any sites that talk about OS development, and none of that is interesting to make it to more mainstream media coverage anymore?

_________________
Amiga! The computer that inspired so many, to accomplish so much, but has ended up in the hands of . . . . . . . . . .

@amigadave

Nobody would use an improved AmigaOS anyway. The only reason people still write Amiga software anymore is to show off what a 30 year old computer can do.

Taking the MiniMig graphics core as an example, it only takes a small FPGA to implement. It's so far from being competitive that even making the clock speed faster so the blitter clocks at modern speeds and the copper can make chunky graphics at good resolution would be pointless. Why? The challenge is gone at that speed. Nobody would be impressed by the skills needed.

I started writing a Graphics.library replacement but there is still no point. Only new software would be able to use it because even if it removed all the inefficiencies of the original Graphics.library, it won't get into the hands of developers 20 years ago. It also won't replace Exec.library with anything capable of multiprocessing.

All the great engineering of hardware and software early on in the history of Amiga wouldn't make up for all the boneheaded mismanagement of the later years. The management decisions toward the end suggest corporate espionage on the part of any and maybe all of Commodore's competitors. They couldn't have messed up such a head start without actively trying.

@Samurai_Crow

Nobody care what a 30 year old computer can do.
People still write Amiga software because people love Amiga OS and has a lot of memories with it.

@Samurai_Crow

Quote:

Nobody would use an improved AmigaOS anyway.

I would.

Linux is at least 100 times as complex as AmigaOS. A new AmigaOS that's 10 times as complex as 3.1, but only one-tenth as complex as Linux might be a real sweet spot. Obviously these number are arbitrary.

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

@Samurai_Crow

I would use an operating system that gives me the Amiga UX ontop of modern kernel and frameworks etc. Kinda like SerenityOS only with something akin to Amiga rather than “windows”.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

amigadave Quote:

I don't pretend to know anything about OS design, or how exactly the hardware of our Amiga computers work, but I do have a rudimentary understanding of each. Given all of the hindsight that 36 years of use has given our community, and the obvious talent that many Amiga users have. I have to wonder why a better OS for the Classic Amiga hardware has never been created. I'm talking about an OS that breaks backward compatibility with the original AmigaOS, but keeps all of the best things about it and improves upon them. I think that is what AROS should have been, instead of just trying to recreate or reverse engineer AmigaOS3.1, but I don't know enough about AROS to say exactly what it is, or if it does attempt to fix all of the short comings of AmigaOS3.1, but I'm pretty sure that it still has most of the limitations of AmigaOS3.1.

The Amiga hardware has a low average specification which makes it difficult to improve the OS or have anything but the slimmest possible OS for the features of the Amiga. AmigaOS 3.1.4+ would not run on most of the Amiga hardware models sold in the 1980's (1MiB ECS) and barely runs on most Amiga hardware models from the 1990s (2MiB AGA). Even on a 2MiB Amiga and replacing the ROM, AmigaOS 3.1.4+ may use too much memory for some AGA programs to run. Why has AmigaOS 3.1.4+ sold successfully when it wouldn't run on perhaps 75% of the Amiga hardware being used when CBM went bankrupt? I expect it is because the average Amiga spec has improved because of retro hardware, FPGA hardware and emulation which allows the AmigaOS to improve. It would be possible to reduce the AmigaOS footprint with more 68k assembler code (which CBM did but AmigaOS 3.1.4+ moves away from) and compiling for both a 68000 and 68020 target which would also improve performance but it starts to get difficult to make improvements while targeting such low specs. Breaking compatibility doesn't help much as heavy "improvements" like using MMU pages wastes too much memory for page alignment and page definitions, slows the system and responsiveness and most Amiga hardware didn't have a MMU anyway (emulated MMU performance is also poor). The average low spec of classic Amiga hardware is limiting AmigaOS improvements and AROS 68k is also having trouble reaching it's goal as an AmigaOS replacement with the same footprint and performance. Standard Amiga hardware diverges with modern Amiga hardware replacements and the performance/price ratio is lacking except for emulation which has inconsistent performance and fails to create a standard as it is a moving goal post. Emulation should be at a performance/price disadvantage compared to mass produced hardware due to inefficiency but no Amiga hardware is mass produced anymore.

amigadave Quote:

Regarding new PC hardware, now that hardware has become so many orders of magnitude faster than the 7MHz 68000 Classic Amigas and almost anything can emulate it, I think it would be great to see a new OS that has all the great ideas of the original AmigaOS, but none of its limitations, and it could have an Amiga emulator included with it to allow sandboxed backward compatibility. This is what I was hoping the MorphOS Dev. Team would create with their port to x64 hardware, but that does not appear to be what they are doing, from the initial proof of concept that has been demonstrated a couple of times in public.

The problem with a next generation AmigaOS for high performance hardware is a marketing one. There is extreme saturated competition for full featured OSs on high performance computer hardware and much of the competition is free and/or has a major competitive advantage due to existing software compatibility. I know many Amiga users want this but billions of dollars likely couldn't achieve single digit market penetration. The Amiga was good at doing more with less so lower the aim and look at the impact of Raspberry Pi standards and retro hardware recreations which were achieved with millions of dollars. These are mass produced low spec hardware standards which are higher spec than any classic Amiga hardware. Create a successful modern Amiga retro and embedded hardware standard and maybe eventually a next generation AmigaOS for higher performance hardware could run on it.

amigadave Quote:

Why don't we hear about new OSes being developed, or maybe I just don't visit any sites that talk about OS development, and none of that is interesting to make it to more mainstream media coverage anymore?

New OS development and innovation is mostly dead due to ingrained OSs and free OSs. Most OSs are regurgitations of Linux. What modern OS development which could scale to the desktop has innovation, improvements and support from tech giants? Fuchsia maybe?

https://en.wikipedia.org/wiki/Fuchsia_(operating_system)

It may be too much of a research OS and not organized enough or maybe a successor to Android which addresses deficiences and may scale better up to the desktop and servers to compete with Windows and Linux. Security is so important today for higher performance computers and that is where a Windows and Linux replacement could avoid many of their legacy mistakes. Replacing a popular OS with software compatibility is still an uphill battle. Replacing Android would be difficult enough while replacing Windows anytime soon would be nearly impossible.

Fuchsia is already installed on consumer devices, so I don't know about "research OS"... the obvious thing for Google to do, is to replace Linux under the hood of Android... not replacing Android, but replacing Linux.

As for new operating systems... I already mentioned Serenity, and there are certainly others as well. But what does it matter when "operating system" these days merely means "user interface for proprietary firmwares" - the operating systems have less and less actual control over the hardware, everything is abstracted away to fit old paradigmes of what a computer is.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Samurai_Crow Quote:

Nobody would use an improved AmigaOS anyway. The only reason people still write Amiga software anymore is to show off what a 30 year old computer can do.

AmigaOS 3.1.4+ sales indicate otherwise and this is with some Amiga users like me refusing to buy it from Hyperion and with still a quite low average spec for Amiga hardware. At least there are more customers than for AmigaOS 4 while the highest performance Amiga hardware barely surpasses the performance of a 68060. I believe there is more classic software development for enhanced Amigas than stock ECS+1MiB and AGA+2MiB standards even though most of the software is still ports. I believe more Amiga users have or would like to have enhancements than are using stock Amigas. It is not just what the 30 year old computer can do but what the 30 year old technology can do today when updated and enhanced. I expect a lot more ex-Amiga users would be interested to know if the performance was 10 times and the cost 1/10 of some of the current Amiga hardware.

Samurai_Crow Quote:

Taking the MiniMig graphics core as an example, it only takes a small FPGA to implement. It's so far from being competitive that even making the clock speed faster so the blitter clocks at modern speeds and the copper can make chunky graphics at good resolution would be pointless. Why? The challenge is gone at that speed. Nobody would be impressed by the skills needed.

There will always be respect for developers who did so much with so little. It's like a grandparent who walked 10km to school each day even in the winter which is awesome and hardcore but most people don't want to do that today.

Samurai_Crow Quote:

I started writing a Graphics.library replacement but there is still no point. Only new software would be able to use it because even if it removed all the inefficiencies of the original Graphics.library, it won't get into the hands of developers 20 years ago. It also won't replace Exec.library with anything capable of multiprocessing.

I know the frustration. Frank Wille was recently looking into inconsistent floating point results on the Amiga in vbcc.

Rounding differences in mathieee and 68k FPUs
http://eab.abime.net/showthread.php?p=1497476

There are 3 different rounding results depending on using the 68k FPU, Amiga math IEEE libraries or PPC/x86 FPU. The answers, including from ThoR, don't cover which is the closest answer and only why the Amiga ieee libraries may not be as accurate. The most accurate answer is...

1. 68k FPU
2. PPC/x86 FPU
3. Amiga ieee libraries (because of original default C trunc rounding instead of round to nearest)

The calculation is simple yet the 64 bit FPU has already lost 1 bit of accuracy. The 68k extended precision FPU gives the best possible answer in this case but only because the intermediate extended precision results were not truncated as the functions were inlined and roundoff errors were avoided. If the functions were not inlined then the intermediate precision could be truncated leading to inconsistent results. The values are double precision and placed on the stack as double precision but truncating that extra precision can cause problems in rare cases and inconsistencies. The x86 FPU has similar problems which has been responsible for hundreds of GCC bug reports.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

The problems are described well in the following paper.

The pitfalls of verifying floating-point computations
https://hal.archives-ouvertes.fr/hal-00128124

The fix for the 68k is simple which is to always pass extended precision floating point args to functions. Of course this is not efficient with args on the stack as specified by the SysV 68k ABI. We need a new ABI which will finally allow the Amiga to use the full advantage of extended precision calculations. We could change the integer args to be more efficient while we are at it. There was research done for the 68k on how many register args would be the most efficient.

Methods for Saving and Restoring Register Values across Function Calls
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.4669&rep=rep1&type=pdf

Our new ABI should look something like the following.

data registers: d0-d3 scratch and function args
address registers: a0-a1 scratch and function args
floating point registers: fp0-fp3 scratch and function args

Additional floating point registers would be placed on the stack in extended precision. Extended precision floating point problems are solved and register args are more optimal. Then I started thinking, who is going to use this new ABI if I go to the trouble of documenting it and pushing for its implementation in 68k compilers. I learned something and know how to fix mistakes but its difficult to fix now. It could be useful for a 68k64 ABI if it was decided to keep the extended precision FPU. An extended precision FPU should be able to provide true quad precision floating point using double extended arithmetic which double double arithmetic of a 64 bit FPU is not capable of as the exponent is smaller than the quad and extended precision exponent which is the same size.

https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Double-double_arithmetic

We can't fix a retro only Amiga but there are more possibilities to fix a competitive Amiga which starts with competitive hardware.

Samurai_Crow Quote:

All the great engineering of hardware and software early on in the history of Amiga wouldn't make up for all the boneheaded mismanagement of the later years. The management decisions toward the end suggest corporate espionage on the part of any and maybe all of Commodore's competitors. They couldn't have messed up such a head start without actively trying.

CBM never really had a good plan for the Amiga which started with upper management not really understanding it. They expected it to magically become the next C64 on its own and all they needed to do was cost reduce it to a similar price range. Performance is as important as price to value which they didn't understand. Espionage may have been a factor early in the life of the Amiga but by the time CBM went bankrupt, the performance was so noncompetitive that competitors were not interested in buying the Amiga.

Last edited by matthey on 30-Sep-2021 at 12:40 AM.

@matthey

Thanks for the thoughtful and well written (understandable to average users) replies to my questions. I have no delusions that anyone, or any group of programmers could dethrone Windows, or even Linux, from the desktop OS realm. It's more of a question about the hobby coding arena, like what surrounds the Raspberry Pi, where I think a group of Amiga, and ex-Amiga developers could create something that has all the best ideas and great performance on the relatively low spec Raspberry Pi hardware, that would resemble the spirit and flavor of the original AmigaOS. I think a lot could be done with a starting point of the Raspberry Pi 4 hardware, knowing that future Raspberry Pi models will likely remain backward compatible or easily ported to. Imagine what could be accomplished if the same efficiencies were recreated similar to how Amiga developers got so much performance from a stock A500, if they could do the same or close to the same on hardware as powerful as the Raspberry Pi 4.

I don't see Windows or Linux being replaced in the future, but I can envision a group of Amiga enthusiasts someday creating something great and with the same feeling of ease of use and better performance than what is currently available for the Raspberry Pi. Maybe it will just be a reworked Linux distro that breaks a lot of the current rules, but retains the ability to run current Linux software, or if not direct ability to run Linux software, perhaps it would require recompiling the software, but the OS could somehow use, or easily modify current drivers for use, so that tons of work would not need to be reinvented again.

Or maybe this is all uninformed dreaming and none of these ideas is practical, or even possible. It would be great to see an Amiga-like hobby OS created for the Raspberry Pi, or some similar mass produced, cheap but fairly powerful hardware design. Emulating AmigaOS is so good now, compared to 15 or 20 years ago, and it is fun to see AmigaOS running so well on current hardware, but it could be a whole different thing if a new OS for hardware like the Raspberry Pi were created, and it contained all the best things that we love about AmigaOS.

_________________
Amiga! The computer that inspired so many, to accomplish so much, but has ended up in the hands of . . . . . . . . . .

@michalsc Quote:

michalsc wrote: @cdimauro Quote: AROS has a 64-bit flavor and also MorphOS seems to being ported to x64, but I have no idea about how they implemented library calls. Keeping the 6 bytes convention they might: - load an offset to a register; - do a short jump to some (common) library's code which is near the library header; - finally, the common code takes the offset, calculates the real address to jump to, and then makes the final jump. But it's just an idea. In case of AROS the LVO table does not consist of the jumps to the library base. Instead AROS uses LVO table containing the addresses of jump targets, only. Therefore, on 32bit AROS targets the LVO consists of 4-byte entries, on 64bit AROS targets LVO consists of 8-byte entries. Fetching target address is just as effective (or even more effective) than jumping into LVO. That saves us one unnecessary jump :)

Thanks for the clarification. That's a very smart decision, because it both improves the performances, as you said, while still allowing to change libraries entry with SetFunction, in pure Amiga "philosophy".

It means that the R in AROS is not there just by accident.
Quote:

PS. The only exception from this rule are m68k targets, where the binary compatibility is important. There, the LVO is just as it is on AmigaOS - series of JMPs into library

Yes, 68K should be API and ABI compatible by AROS' goals, but it's also needed because 68K has no jump/call fetching from memory (another big mistake of 68K engineers: treating EA on JSR/JMP like LEA/PEA instead of how it works with all other regular instructions), except for 68020+ (but using the more expensive double memory indirection).

@matthey Quote:

matthey wrote: cdimauro Quote: This is one of the other big mistakes of the Amiga o.s. developers: they should have aligned the library call entries to 64-bit size / 8-bytes to favor faster access to 32-bit processors and the ones with data caches. The whole Amiga platform, both hardware and software sides, seems to be affected by the "16 bits ought to be enough for anybody" mantra... Hind sight should be 20/20 but the situation needs more historical examination from the time the Amiga was created. There were severe resource limitations at the time the Amiga was created to be more dynamic than any personal computer up to that time.

I understand this, but mistakes remained and crippled the Amiga. I know that they are in hurry to complete the platform, but we know the results of this big rush...
Quote:

The dynamic design and flexibility of the Amiga can be seen in the 68k CPU choice which allowed for 32 bit pointers, a flat memory model and address 4 being the only fixed address in the Amiga.

The last is another big mistake of the Amiga o.s. developers: Exec/SysBase should have been passed to applications at the startup, and giving the applications to decision to save it where they wanted. That's because $4 is Chip RAM, which is SLOW and NOT cachable...
Quote:

The copper and blitter are significantly more flexible than earlier designs and were copied in newer hardware.

I don't know of any Copper "copy".

Blitter was copied (albeit IBM's EGA had already some bitplanes operation logic embedded), but only the good part: a coprocessor that can accelerate graphic primitives. The rest was done using packed/chunky graphics, which was almost always the best solutions (globally, bitplanes for graphics is the worst format ever), as Jay Miner also wanted to have (too late).
Quote:

The Amiga developers could have used a 68020, more memory, VRAM (dual ported memory) for gfx and new custom processes for chip fabrication allowing for more transistors but the result would have been more like a more modern and expensive Apple Lisa than a computer for the masses.

Nobody is saying that: the Amiga 1000 was already quite expensive. But at least a 68010 could have helped a bit and didn't required a specific o.s. API to deal with another Motorola mistake (MOVE SR/CCR), not even counting the problems which the 68000 choice gave to game developers for that...
Quote:

Not all the Amiga structures use natural alignment for datatypes either. The 32 bit 68020 was released in 1984 before the Amiga was released so the developers should have known better. Even the 32 bit registers in the 68000 should have been enough of a clue to naturally align all 32 bit datatypes. It doesn't require much CPU hardware knowledge to see this today but many of the Amiga software developers likely came from programming 8 bit computers with no caches. Still, the extra cycle here and there necessary for accessing unaligned data on the 68020+ is partially made up for by more compact data using less of the DCache. The same is true for the jump tables which are unaligned code using less of the ICache. The variable length instruction set of the 68k allows more compact code and better ICache efficiency usually giving better performance than less than optimal alignment would indicate. Branch targets in 68k code were and are rarely 4 byte aligned even on the 68020 where my Cape manual claims a ~5% performance improvement for 1-2% code enlargement. While I too would prefer 8 byte jump table entries today, the original Amiga was planned to have 256kiB of memory which may have left less than 100kiB free after boot and larger jump tables for all libraries would have taken a few more kiB of this away. Let's not forget how early the Amiga was before we accuse the Amiga developers of mistakes.

How many libraries were available at the time? How many APIs they were exposing? How many structures were used? I don't think that choosing the right alignment on all that would have gnawed at so much memory: a few more KBs, like you already stated (which is inline with the 1-2% enlargement that reported).

As I said before, I understand the context, but they rushed too much to finish the work in time, and IMO this led to plenty of mistakes which the platform is still paying.
Quote:

AROS x86-64 has no backward compatibility to worry about. Michalsc tells us how foreign architecture AROS jump table entries are formatted which if I understand correctly would resemble something like the following on the 68k. move.l (-32,a6),a0 ; get data from -32 offset of jump table jsr (a0) ; call library function jsr ([-32,a6]) ; similar code as above using double memory indirect (same code size but saves a reg)

No, for x86/x64 is more similar to the double memory indirect. Something like:

CALL DWORD PTR [EBX-32] ; x86
CALL QWORD PTR [RBX-32] ; x64

which takes 6 bytes (opcode + MobR/M + 32-bit offset).
Quote:

The code is 6 bytes for every function call instead of 4 bytes for jsr (-32,a6) as existing Amiga libraries currently use. It is better to use larger code in the jump table which is shared than enlarge all function call code.

Yes. Here the plain 68K has an advantage, but at the expense of executing one more instruction.
Quote:

Even the 68060 can reduce the cost of a jmp xxx.l in the jump table to 0 cycles folding the branch away so there isn't much of a performance problem albeit less than efficient ICache used for jump table entries and branch cache entries used. With 6 bytes of overhead per function call, we could use the following code. jsr xxx.l The 68060 can execute the code in 1 cycle when the address is in the branch cache (return address needs to be pushed onto the stack so not 0 cycles). The libraries to open could be specified in the executable and the absolute addresses of function calls could be updated with proper addresses much like is done for a RELOC. On program termination, the libraries would be closed. Support could be added to the existing AmigaOS and would reduce function call overhead to a bare minimum (1 cycle jsr+ 7 cycle rts as 68060 has no hardware link/return stack but ColdFire v4 has a 2 cycle rts).

In fact, that was my proposal: just use calls/jsrs using absolute addresses. However it's much more difficult to implement it, and even more difficult if you want to keep the SetFunction compatibility.
Quote:

The scratch register needed for the AROS 32 bit method is also saved

Not needed: see above.
Quote:

although some RISC architectures do not have absolute addressing.

RISC architectures cannot have an absolute addressing mode: this is a CISC privilege.
Quote:

While this method is nearly optimal for 32 bit addressing, it is less than optimal for 64 bit addressing as jsr xxx.q becomes 10 bytes for each function call because the 64 bit absolute addressing uses 8 bytes for the address. Absolute addressing is best avoided for 64 bit addressing and position independent code using PC relative references is more desirable.

In fact that's the way to go for 64-bit ISAs.
Quote:

It is possible to combine the library structure and table with the library code. The big advantage is that the whole library can be addressed with PC relative addressing and the a6 and a4 registers are freed as they are no longer needed as pointers. The disadvantage is that the library can't be used from ROM. Of course ROM has been replaced by NAND flash memory today. The disadvantages of NAND flash memory has been that it is lower performance than DRAM and that it has a limited number of read/write cycles but performance has improved over time and the read/write cycles have increased from 100,000 to 100 million for some types.

This is only important for the embedded market, where applicable. But it's an important and valid point.
Quote:

Quote: cdimauro [quote] True: Amiga libraries are very nice, simple, and efficient solutions to share code. Nowadays I would have preferred a slightly but more efficient mechanism: replacing a library call with a JSR/CALL to an absolute address (for 32-bits code; to a RIP relative offset for 64-bit systems), to avoid the double jumps (or some stub code). Yes, 32 bit addressing is easy as absolute addressing is efficient. Just need to lock the libraries of function calls into memory by having the loader open them as I have described above and then adjust the absolute addressing addresses to the final destination function entry points. I don't see how the RIP relative addressing, which uses a 32 bit register (max PC relative offset), allows to use the whole 64 bit address space. Even with virtual addressing to map libraries within 32 bit addressing distance (~4GiB) this seems rather limiting for a fully dynamic 64 bit OS with executables which are several GiB in some cases today. Could you please give some specifics of how you would make this work?

That was the idea: remapping libraries' code around the application code. If you put the application code right in the middle of a 4GB area, then you can use remaining parts from -2GB to +2GB to remap libraries' code.

It's true that there's a lot of code nowadays, but I doubt that a single application / process uses, on a specific timeframe, so many libraries at the same time to completely fill, or even exceed, the above 4GB area.

As alternative, CALL/JMP on my ISA can have up to 41 bits signed offset from PC (using 6 bytes max): "+-1 trillion offsets ought to be enough for anybody"...
Quote:

Quote: cdimauro [quote] That's a big problem, because it requires either a PMMU (which you don't like) or duplicating the library header + jump table each time that a library is opened by a task/thread/process. The MMU is a valuable tool. Just because I recognize the significant overhead of virtual addressing and process isolation does not mean I don't like it. I would prefer to have an Amiga with a MMU and for the AmigaOS to optionally support the MMU to improve reliability. I recognize that the current generation of AmigaOS can't have full process isolation but it can have partial memory protection provided with the MMU likely with a lower overhead compared to full and having the advantage of providing this optionally to conserve resources and improve responsiveness where it is too expensive. Such a 64 bit Amiga would need a different approach than trying to remap addresses closer together using virtual memory which has overhead and is pretty limiting with 32 bit RIP relative addressing anyway.

You don't need a 64-bit system to have partial memory protection for Amiga tasks: even on a 32-bit 68K (with MMU, of course) you can implement it, with minimum overhead. The o.s. (developers) has to be smart.

BTW, PMMU must be enabled on x64, but at least you can have very large pages which can be used to mitigate the costs of page translations.
Quote:

Quote: cdimauro [quote] As usual, in the Amiga land: very short vision. They've just gone for quick (and often dirty) solutions to the problems which suddenly popped-up during the development... Most of the Amiga solutions were simple and needed to be simple when the Amiga was developed. Mistakes were made and large gaps without significant development occurred. The same could be said of the 68k but we have to remember the 68000 was released in 1979 and the Amiga in 1985. What other personal computer from the 1980s is as flexible and dynamic as the Amiga? What other computer from the 1980s can adapt to appear as modern and easy to use as the Amiga while retaining good compatibility, a tiny footprint and a responsive GUI down to a 1 DMIPS CPU?

I've no problem to contextualize it, but I think that such mistakes (and we've MANY on both 68K and the Amiga platform) were caused either buy too much rushing to meet the deadline or by lack of experience on designing such products.

My idea is that those engineers were very short sighted: they just applied the first, simple solution to the problems that they are discovering during the development. With all issues that came from it, which were borrowed nowadays.

Finding and applying better solutions require time: time for increasing own experience, and time allocated for the project. The worse comes if you lack both...

@Samurai_Crow Quote:

Samurai_Crow wrote: @amigadave Nobody would use an improved AmigaOS anyway. The only reason people still write Amiga software anymore is to show off what a 30 year old computer can do. Taking the MiniMig graphics core as an example, it only takes a small FPGA to implement. It's so far from being competitive that even making the clock speed faster so the blitter clocks at modern speeds and the copper can make chunky graphics at good resolution would be pointless. Why? The challenge is gone at that speed. Nobody would be impressed by the skills needed. I started writing a Graphics.library replacement but there is still no point. Only new software would be able to use it because even if it removed all the inefficiencies of the original Graphics.library, it won't get into the hands of developers 20 years ago. It also won't replace Exec.library with anything capable of multiprocessing.

The best thing that you can do is reusing part of what was made, and create something which is inspired but not 100% compatible.

Trying to enhance a platform, both hardware and software, has its limits IMO, primarily because of the legacy and many mistakes that this old platform still carries.

A modern platform which meets modern requirements could have better chance to attract people/geeks from the legacy platform AND novel people/geeks which are naturally interested on new, cool stuff. And if the new ground is good, it might have a chance to polarize wider attention and even capitals.
Quote:

All the great engineering of hardware and software early on in the history of Amiga wouldn't make up for all the boneheaded mismanagement of the later years. The management decisions toward the end suggest corporate espionage on the part of any and maybe all of Commodore's competitors. They couldn't have messed up such a head start without actively trying.

I beg to differ: I don't see so much great engineering on Amiga: there were so many mistakes and bad decisions that it's possible to write a book only talking about that!

I think that we, as amigans, are still too much biased about our beloved platform, and this continues to distort our vision, which detaches from reality.

Another thing where many amigans are trapped is the "what-if" drama. What if engineers could have made this? What if Commodore have made this? And so on, falling on this endless loop of useless discussions.
The past is the past. Dot.

If people wants to better spend its time, I suggest to avoid such discussions and use it for building something cooler ("Amiga-inspired") or even brand new.

And let's enjoy the Amiga platform as it is, as it was left: we still have plenty of software and games, which we can (retro) enjoy...

@kolla Quote:

kolla wrote: Fuchsia is already installed on consumer devices, so I don't know about "research OS"... the obvious thing for Google to do, is to replace Linux under the hood of Android... not replacing Android, but replacing Linux.

Correct. And I hope that it happens soon (Linux is another bloatware), albeit Fuchsia is still another POSIX-compliant o.s....
Quote:

As for new operating systems... I already mentioned Serenity, and there are certainly others as well. But what does it matter when "operating system" these days merely means "user interface for proprietary firmwares" - the operating systems have less and less actual control over the hardware, everything is abstracted away to fit old paradigmes of what a computer is.

I agree. Nowadays there's no need to create an o.s. and/or software which is so strictly tight to the hardware.

@matthey Quote:

matthey wrote: I know the frustration. Frank Wille was recently looking into inconsistent floating point results on the Amiga in vbcc. Rounding differences in mathieee and 68k FPUs http://eab.abime.net/showthread.php?p=1497476 There are 3 different rounding results depending on using the 68k FPU, Amiga math IEEE libraries or PPC/x86 FPU. The answers, including from ThoR, don't cover which is the closest answer and only why the Amiga ieee libraries may not be as accurate. The most accurate answer is... 1. 68k FPU 2. PPC/x86 FPU 3. Amiga ieee libraries (because of original default C trunc rounding instead of round to nearest) The calculation is simple yet the 64 bit FPU has already lost 1 bit of accuracy. The 68k extended precision FPU gives the best possible answer in this case but only because the intermediate extended precision results were not truncated as the functions were inlined and roundoff errors were avoided. If the functions were not inlined then the intermediate precision could be truncated leading to inconsistent results. The values are double precision and placed on the stack as double precision but truncating that extra precision can cause problems in rare cases and inconsistencies. The x86 FPU has similar problems which has been responsible for hundreds of GCC bug reports. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30255 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 The problems are described well in the following paper. The pitfalls of verifying floating-point computations https://hal.archives-ouvertes.fr/hal-00128124 The fix for the 68k is simple which is to always pass extended precision floating point args to functions. Of course this is not efficient with args on the stack as specified by the SysV 68k ABI. We need a new ABI which will finally allow the Amiga to use the full advantage of extended precision calculations. We could change the integer args to be more efficient while we are at it.

I reply only to this part, because I don't care at all about the "what-if" etc. and trying to revive a dead platform.

Using the extended precision is overkill: which software uses it? I mean software for currently used applications. I bet a bunch of them, and this could be only on scientific computing and similar.

Modern software uses single or double precision. Dot. There's no space for extended precision on current software, and nobody will change such code only for that!

Quad precision (e.g.: 128-bit) arrives in future, for sure, but again it'll be for scientific computing. And, BTW, it'll exceed 68K's AND x87 extended precision.
Quote:

There was research done for the 68k on how many register args would be the most efficient. Methods for Saving and Restoring Register Values across Function Calls https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.4669&rep=rep1&type=pdf Our new ABI should look something like the following. data registers: d0-d3 scratch and function args address registers: a0-a1 scratch and function args floating point registers: fp0-fp3 scratch and function args Additional floating point registers would be placed on the stack in extended precision. Extended precision floating point problems are solved and register args are more optimal. Then I started thinking, who is going to use this new ABI if I go to the trouble of documenting it and pushing for its implementation in 68k compilers. I learned something and know how to fix mistakes but its difficult to fix now. It could be useful for a 68k64 ABI if it was decided to keep the extended precision FPU.

Very interesting study, thanks.

It's good to use for new o.s. & applications, but certainly not for the extended precision (see above).