@matthey

Quote:

The problem is people that blindly copy and paste information may spread misinformation. Ron Nicholson said Amiga Corporation had an Apple II, ordered and were on the waiting list for an Apple Lisa and later bought a multi-user Sage workstation. The Lisa would have been an influence while designing the AmigaOS and the AmigaOS was likely an improvement from cooperative to preemptive multitasking. This may not seem important but it could be important for the Amiga as pre-emptive multitasking requires guarantees for the operating environment that changed from a single core to a multi-core environment but it may be possible to restore the guarantees in a multi-core environment like I suggested (cooperative multitasking has no guarantees). Whether the hardware changes are a dirty hack or should be patented is up for debate but unfortunately the corruption around the Amiga has a suppressive sabotaging non-intellectual aura about it. There will be no Amiga enlightenment or Amiga golden age until there is leadership change.

FYI, Apple Lisa also had MS Xenix 68K port in 1984 along with MS's text UI business software library. Apple Lisa has custom MMU and ECC memory support.

ECC memory support was one of the key features for the SUN / HP Unix 68K solution vs others.

Pentium Pro's chipset gained an ECC memory feature for the clone PC hardware market.

Quote:

The GUI was optional in other OSs like the Amiga. Multitasking is useful from a CLI. The Sinclair QDOS was a small footprint 68k OS: "Very little memory demanding OS; the basic QL only got 128 Kb of RAM and only 85 Kb were actually available for the jobs (32 Kb of RAM being used by the screen memory)..." QDOS was: "100% 68000 assembly written OS (it uses only 48Kb of ROM, BASIC interpreter included !) thus very fast."

Multitasking without memory protection is a half-baked solution. QDOS was released in April 1984.

Every 386AT PC has the potential to run MS/SCO Xenix 386. i386 MMU as standard 386AT platform allowed Linux to be created on a 386 PC, not on another CPU family.

Low-cost MIPS R3050 (R3000A compatible) has an embedded MMU, which one up against similar-priced MMU-less 68K.

Sinclair QDOS is a dead duck when compared to MS's Xenix business.

MS planned their independent (from AT&T Unix license entanglements) 32-bit multitasking with memory protection OS future from 1988 i.e., hiring Dave Cutler from DEC's VMS division.

Mac's success was about "next gen" killer GUI apps for business beyond vertical 200/256 pixel lines. Mac's success proves its priorities.

Amiga's Word Perfect port from PC's DOS text UI design was a #metoo, which is inferior Mac's MS Word GUI "next gen" business apps. WordPerfect being late to the Windows GUI would be its fall from the establishment position. I'm aware of ProWrite 1.1's Amiga port in 1987 which I compared it to Mac's MS Word 3.0 GUI. Mac's MS Word 3.0/MS Excel 2.0/Page Maker is a strong combo in 1987. AmigaOS 1.x GUI design is not consistent until NextStep inspired AmigaOS 2.x.

Atari ST's unit sales decline in 1988 occurred after PC VGA/Windows 2.x, color Mac II, and Amiga 500 releases. It was an early warning for the later Amiga ECS.

Last edited by Hammer on 18-May-2025 at 01:35 PM.
Last edited by Hammer on 18-May-2025 at 01:29 PM.
Last edited by Hammer on 18-May-2025 at 01:23 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

Hammer Quote:

FYI, Apple Lisa also had MS Xenix 68K port in 1984 along with MS's text UI business software library. Apple Lisa has custom MMU and ECC memory support. ECC memory support was one of the key features for the SUN / HP Unix 68K solution vs others. Pentium Pro's chipset gained an ECC memory feature for the clone PC hardware market.

Once again, you are all over the place in time, application and price range.

The Apple Lisa is an expensive personal business computer that, like the Amiga, cost roughly $50 million to bring to market but the Lisa was introduced at $9,995 while the Amiga was introduced as a general purpose (creating multimedia?) PC at $1285 about 2 years later using the same 68000 CPU. Both the Lisa and Amiga were borderline workstations but lacked features of Unix like workstations.

1983 Apple Lisa $9,995
68000 CPU with large flat address space (32-bit ISA)
1MiB memory
cooperative multitasking
memory protection, virtual memory and ECC memory
single user
mouse driven GUI with bitmapped graphics
hard drive standard

1985 Amiga 1000 $1,285
68000 CPU with large flat address space (32-bit ISA)
256kiB memory
preemptive multitasking
no memory protection
single user
mouse driven GUI with bitmapped graphics
hardware accelerated with DMA, Blitter and Copper
880kiB floppy standard

The Lisa has some of the features of a workstation but lacks value with its pricing. In some ways, the Amiga is a better mini workstation and the low price allows expansion but high end Amiga hardware expansion was slow to be introduced. The Amiga performance was much better than Lisa performance while using 25% of the memory and at ~13% of the introductory price. The Amiga 1000 was ahead of its time as a multimedia PC but was too expensive for most 8-bit PC users to upgrade and not business oriented enough for a business PC where it was affordable.

I believe the Amiga developers made much better choices based on constraints than the Lisa developers. Memory protection was very expensive at that time including requiring an external MMU chip which was expensive, slow and limited. Also, MMU page tables and page alignment requirements waste memory and memory was very expensive at the time the Lisa was created while fortunately coming down just in time for the Amiga 1000 to ship with 256kiB. The Mac was a cost reduced Lisa and dropped memory protection with memory requirements dropping from the Lisa 1MiB to the Mac 128kiB. Ron Nicholson is the Amiga engineer that talked Jay Miner out of memory protection which I believe was the pragmatic choice based on constraints. The following Ron Nicholson video link is time stamped where he explains why.

Amiga Speech by Ron Nicholson (Amiga Ireland 2023)
https://youtu.be/gG_SvjO8w2o?t=1260

Watch the other video Ron Video in its entirety if you want to know about Amiga constraints.

Ron Nicholson at the Amiwest Show 2015
https://www.youtube.com/watch?v=WIoLuLXjK6Y

Engineering is the art of compromise, based on constraints.

Hammer Quote:

Multitasking without memory protection is a half-baked solution. QDOS was released in April 1984.

Preemptive multitasking only requires a few kiB of memory.

https://kgsvr.net/andrew/amiga/amiga.diffnt.html#realtime Quote:

I have run control software on the Amiga booting off of a battery-backed SRAM PCMCIA card without a hard drive or floppy using only 4K of the PCMCIA card to boot. Think of the PCMCIA card as replacing the hard drive in a desktop system. The only RAM overhead was about 54K, and with this I have the full color model and mouse control, and fully preemptive multitasking and of the 2 Meg of RAM that comes with the A1200, The Amiga OS has only needed less than 1 / 10,000 of the RAM available. And I know it is using a few of the OO Objects in the Kickstart, but not very many.

Of the 54kiB of memory the AmigaOS uses (which I believe is AmigaOS 3.1), several kiB are for drive buffers. The Exec kernel is smaller at only 13kiB according to Carl Sassenrath and the Amiga ROM Kernel Reference Manual.

https://en.wikipedia.org/wiki/Exec_(Amiga) Quote:

Exec is the kernel of AmigaOS. It is a 13 KB multitasking microkernel which enabled pre-emptive multitasking in as little as 256 KB of memory (as supplied with the first Amiga 1000s). Exec provided functions for multitasking, memory management, and handling of interrupts and dynamic shared libraries.

The AmigaOS preemptive multitasking would have been useful with 128kiB of memory if most of the AmigaOS had been mature enough to put in ROM. The Amiga chipset would not have been nearly as impressive though as higher resolutions and max colors would not have been available. You are not suggesting the nearly free AmigaOS preemptive multitasking is not useful are you?

The combination of a large flat 32-bit address space and memory protection likely would reduce the memory in half. Find the earliest PC with both and tell me how much memory is the minimum. I expect it will be at least 512kiB and maybe 1MiB like the Lisa, if not the Lisa. I would choose the large flat address space over memory protection. I would choose the cheaper Amiga with preemptive multitasking, 25% of the memory and no memory protection over an Apple Lisa with cooperative multitasking, memory protection, 4 times the memory and nearly 8 times the price any day. Did you buy the Lisa or the Amiga?

Optional partial memory protection likely is possible in the 68k AmigaOS with a MMU.library like Thomas Richter (ThoR) created when a MMU is available and there is adequate memory. Perhaps Commodore did not think of this or perhaps they did not want customers demanding more expensive 68k CPUs with MMUs. Perhaps Hyperion did not add optional memory protection to the AmigaOS despite ThoR originally being on the 68k AmigaOS dev team because the 68k AmigaOS is designated as a 2nd class citizen to PPC AmigaOS 4 by someone higher up and de facto in control of Hyperion. Perhaps the 68k AmigaOS is designated for emulation only where MMU support is undesirable despite the 68k Amiga market being huge in comparison to the tiny PPC AmigaOS 4 market. Perhaps the 68k Amiga must be sabotaged to recover a malinvestment in PPC AmigaOS 4 hardware. Perhaps even other PPC AmigaOS 4 capable hardware must be sabotaged to recover a malinvestment in AmigaOS 4 hardware.

Last edited by matthey on 18-May-2025 at 06:57 PM.

@matthey

Quote:

matthey wrote: cdimauro Quote: There are ways, but you need to know them. In fact, you don't need to disable paging neither memory mapping (the two things are different, BTW) on modern systems (which more or less offer the same functionalities), rather to use the proper APIs. Spefically, for Windows you need to use: - VirtualAlloc ( https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc ) for manually allocating pages; - VirtualLock ( https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtuallock ) for locking a range of pages so that they aren't swapped out. There are constraints on using them, which require attention and proper coding, but you can set memory regions which guarantee no page faults by carefully & properly combining both APIs. This, united with the real-time priority and setting the process/thread affinity, is the way to reach close to real-time OSes performance. In short, yes: you can go back slim at memory handling even on "pachyderm" OSes. I do not have similar real time responsiveness issues on a 68k Amiga with a fraction of the CPU clock speed and memory.

That's comparing apples and apples: your Amiga is certainly not able to run modern, very complex applications, in a solid environment and with acceptable speed.

Software evolved a lot (included OSes and plenty of libraries covering A LOT of areas), and our current systems are running binaries compiled out from hundred of millions of line of code. Which, of course, require many more resources compared to what could run on an Amiga system with the most complex applications that can be used.
Quote:

I do not appear to be the only one either. https://news.ycombinator.com/item?id=6792425 mnw21cam Quote: Yes, the Amiga had proper honest multitasking. A normal boot of an Amiga system would typically result in over twenty processes running in the background. In fact, its particular style of multitasking (static absolute priorities) was well-suited to real-time operation. Back in the days when CD writers could create coasters from buffer under-runs, I had more success writing CDs using my 25MHz Amiga than my 400MHz PC. Also, it was a microkernel system with things like device drivers and filesystems as separate processes, which had some fairly nifty consequences. For instance, it took Linux ages to lose its single kernel spinlock, which was a problem because of the huge amount of stuff done in kernel space. The thing the Amiga didn't have (mostly because of lack of hardware capability) was memory protection.

Single experiences have no value (even statistically), without a proper induction that proves the presumed thesis.
Quote:

The AmigaOS had preemptive multitasking in 256kiB of memory while the thread mentions the 68k Sinclair QDOS which had preemptive multitasking earlier and used less memory. https://news.ycombinator.com/item?id=6792425 huxley Quote: Sinclair QDOS which ran on the Sinclair QL did preemptive multitasking on a 128KB machine (buggy as heck when it came out but it did precede the Amiga by almost a year and half). Of course QDOS inspired Linus Torvald to develop Linux with a monolithic kernel and the "single kernel spinlock" problem mentioned in the first quote above.

I don't know what was that spinlock problem. However, and as long as it's hidden in the kernel and not exposed externally to the application layer, it certainly isn't a problem (e.g.: that's code which can be completely rewritten without affecting applications compatibility).
Quote:

So how did QDOS provide preemptive multitasking? http://qdos.free.fr/QDOS.html Quote: QDOS: The QDOS is the Sinclair QL operating system (QDOS = Ql Disk Operating System, nothing to do with the "Quick and Dirty Operating System" !). Its main characteristics are: o True preemptive multi-tasking (the programs running in memory are called "jobs"). o No use of any semaphore for shared ressources access. The critical ressources (hardware/shared data structures) are accessed through "atomic" (i.e. not interruptible by another job) system calls. This guarantees that the system cannot suffer from "deadlocks", the main flaw of most (if not all) other multitasking systems. o Dynamic memory allocation to the jobs, no inter-job memory protection mecanism (very flexible but very dangerous too...). o "Channels" oriented inputs/outputs (the jobs access to the peripherals they need through channels). This allows to access peripherals with peripheral independant system calls (for instance "PRINT" and "INPUT" may be used with all the QL peripherals). o All the directory device drivers (mass storage device drivers) benefit from the free memory as a cache (no disk cache software needed and the cache is dynamically allocated). o 100% 68000 assembly written OS (it uses only 48Kb of ROM, BASIC interpreter included !) thus very fast. o The command interpreter is the "SuperBASIC", a structured (Pascal like) BASIC. This is much more flexible and powerful than any classical shell. o Very little memory demanding OS; the basic QL only got 128 Kb of RAM and only 85 Kb were actually available for the jobs (32 Kb of RAM being used by the screen memory)... o High expandability (adding new device drivers to QDOS and new SuperBASIC extensions is actually very easy). o QDOS is a "Plug'n Play" OS. The add-ons cards may have their own ROM which contents (device driver, SuperBASIC extensions) is automatically linked into the system at startup. The ROM address may also be automatically attributed. Among the different QDOS ROM versions (FB, PM, AH, JM, JS, MG), only JS (which equiped English QLs) and MG (which equiped QLs sold in non-English speaking countries) are still in use nowadays, albeit there could still be some antediluvian QLs with a JM or even an AH ROM around... Because of the very limited ROM space, some useful system management extensions were missing from SuperBASIC. The Toolkit II (either held in a ROM cartridge, in an extension file to be loaded in RAM or in some add-ons on board ROMs) fills these gaps. As you can see Micro$oft did not invent anything and a "plug and play 32 bits preemptive multitasking operating system for personal computers" was already available 11 years before Windoze 95; the previous Windoze versions were using the 16 bits addressing mode of the x86 (which is much less efficient than the 32 bits addressing mode of the 680x0 or 486/Pentium), and were not preemptive (but cooperative: i.e. the responsability of the task switching initiative is left to the application instead of the OS: many crashes guaranteed !). "No use of any semaphore for shared resources access" and "atomic" "not interruptible" code sounds like the AmigaOS.

Well, it shares the same processor, more or less, and it's a single processor system: you need no hardware locks, and once you've disabled the interrupts your code can't be interrupted (!) any more.

But then, and probably, it has the same problems when coming to the SMP...
Quote:

1981 MS-DOS - no multitasking until limited and abandoned 1986 4.0, 16-bit limitations 1983 Lisa OS - cooperative multitasking 1984 QDOS - preemptive multitasking 1984 Mac OS - no multitasking until 1987 System 5 introduced cooperative multitasking 1985 Atari TOS - no multitasking until 1990 with Mint/MultiTOS 1985 AmigaOS - preemptive multitasking 1985 Windows - cooperative multitasking until Windows (19)95, not full OS, 16-bit limitations 1987 RISC OS - cooperative multitasking Unix was around from the 1970s but it was not a PC OS where backward compatibility was important so the fact that it did not originally support multitasking, was not portable and had 16-bit limitations was less of a problem. The major reason it was not used for PCs was that Unix was expensive, required expensive hardware and was a resource hog.

Albeit it was released only on 1987 (like RISC OS), MINIX proves that Unix can be implemented even on a poor 8086 PC.
Quote:

OS-9 had preemptive multitasking from inception, was cheaper than Unix and was an optional OS for several PCs but was not used as the default OS for any PC that I am aware of.

I don't know it as well, but it looks like that it suffered from similar problems of the Amiga OS (single address space & shared resources).
Quote:

So which PC OS from the 1980s that maintained compatibility was better than the "very badly designed" AmigaOS?

That's a Red herring + Straw man: you're trying to change the topic and not recognizing what was the real problem under discussion.

The Amiga OS was very badly designed for the reasons which I've already explained (much more in detail on the Amiga "NG" article which I've written time ago).

The fact that it has preemptive multitasking does NOT imply that it had a good design. In fact, this is a FEATURE of the OS that was implemented and made available. However, it has nothing to do with the very bad decisions that I've already mentioned. Neither the presence of this very good feature could cancel or mitigate the assessment of those bad decisions.

This clarifies the context and related facts, putting also the logic to the right place.

Anyway, I can (also) give an answer to your question: Xenix.

And I can give another answer: Windows 1.0, which had a good design with getters, setters and enumerators to access relevant information about its PRIVATE structures, with a very good good level abstraction.
Quote:

cdimauro Quote: But this isn't "68k SMP": this is "trying to introduce the SMP on the Amiga OS" (which can't have it because it's very badly designed). The 68k SMP tools I propose would likely be useful at getting the Sinclair QDOS working with SMP too. It would not help all the retro cooperative multitasking OSs which are very "very badly designed" or the non multitasking OSs which are very very "very badly designed".

In fact, it's an ad-hoc addition to the 68k family with the only purpose of TRYING (it should be highlighted, again) to introduce SMP on very badly designed (without quotes) 68k OSes like the Amiga one.

Because the 68k had already built-in SMP support, since the very beginning, and an OS with a Good Design would have simply used it without any introduction of horrible patches.

In fact, no sane OS would have exposed its internal structures and even provide APIs like Forbid/Permit/Disable/Enable, to take full control of the machine at the application level. Which is the KEY POINT of this part of the discussion, just to be perfectly clear and aligned.
Quote:

The x86 CPUs had hardware support to maintain MS-DOS and Windows compatibility with real mode, unreal mode,

x86 had no "unreal" mode: it was just a name/label used to identify the trick used to setup the 386's selectors registers in a way that allows DOS applications to access the full 4GB address space without necessarily going to protected mode.

That was a perfectly "legal" way to use 386s processors and certainly not a patch from Intel to keep backward compatibility with DOS and Windows.
Quote:

virtual 8086 mode,

That goes to the virtualization area, which all mainstream architectures introduced at some time to support running multiple-OSes.

Not the Motorola case with the 68k, because it was going to the opposite direction: cutting features to the processors to reduce the numbers of transistors used.
Quote:

16-bit protected mode, 32-bit protected mode,

Protected mode was introduced by Intel only to get military grade I security certification for its processors, and certainly NOT for the DOS/Windows backward-compatibility.

In fact, it was completely incompatible with DOS: it was a completely new world (and added with the sole purpose to support very secure OSes with required particular hardware capabilities). 286s not even had the chance to go back to the real mode to run DOS (besides a bug / undocumented feature).

BTW, Windows was not even in development when it was introduced...
Quote:

compatibility mode,

Compatibility mode is the regular x86 operational mode which such processors family had up to the introduction of AMD's x86-64. It was AMD which used this new label to identify the execution mode up to 32-bit.

In short, nothing new.
Quote:

64-bit mode,

It's "simply" the extension to 64 bits.

How would you call the 64-bit execution mode of your 68k extension?
Quote:

system management mode,

That was introduced to go beyond the Hypervisor (which was beyond the virtualization).

Again, extensions required by the market, which Motorola never introduced.

BTW, extensions for servers, where DOS and Windows compatibility wasn't certainly a requirement...
Quote:

virtualized I/O,

Same as above: virtualization extensions...
Quote:

multiple memory models including segmented (address bank switching)

Same as above: selectors came with the protected mode, which was NOT required by DOS (Windows didn't even exist).

Segments were built-in since the 8086.

So, what's your point here?
Quote:

with and without MMU

MMUs were introduced even for 68ks, but guess what: they were NOT needed to keep any Amiga OS backward-compatibility...
Quote:

and 32-bit/64-bit flat address space,

Those belong to 32 and 64-bit extensions: nothing which was built for the DOS/Windows backward-compatibility.

BTW, the 80386 / 32-bit mode was introduced on the same year of Windows 1.0...
Quote:

protection rings,

Same as above: implemented with the protected mode, which was needed to get the MILITARY GRADE to Intel's processors.

Certainly NOT for the DOS backward-compatibility (and Windows was introduced only THREE years later).
Quote:

etc. Much of this support is complex and kludgy but Intel avoided the disaster of losing the desktop market to the 68k which has a single mode and 32-bit address space from inception.

See above: that's plainly wrong. Sorry, Matt, but this is technically and historically inaccurate. You should better check how the x86 processors worked and evolved.

Or you're "simply" (!) too much biased to correctly evaluate the situation, with the sole purpose of advocating the introduction of an horrible patch to 68k (the entire SoC!) just to TRY (repeated, again) to bring SMP support to the Very Badly Designed Amiga OS.
Quote:

Ironically, Motorola started stripping out 68k compatibility and desktop features for the embedded market before surrendering the desktop market with the AIM Alliance agreement.

Wrong again! Motorola started to do it SEVERAL YEARS (a decade!) BEFORE!

Every single new 68k processor was NOT fully (e.g. supervisors and/or user mode) backward-compatible with its predecessor! Not a single one! Even the 68010 with the 68000.

Motorola NEVER cared about backward-compatibility with its processors, since the very beginning of its history!
Quote:

In comparison to all the x86 compatibility baggage, the 68k hardware compatibility support I propose is relatively simple.

See above: x86 never had to introduce horrible patches to the ISA with the sole purpose of maintaining the backward-compatibility with the existing software (not only DOS. And not only Windows, once it was LATER introduced).

Those were part of the natural evolution of this processors family, which were simply (!) trying to "fill-the gap" with the competition (e.g. 32-bit mode), or adding new features to cover NEW markets.

What you're proposing is an addition to the 68k ISA specifically with the purpose of helping the Very Badly Written Amiga OS with a possible (but impossible, in reality) SMP addition.

Do you spot the difference?
Quote:

I would also connect the necessary lines from 68k CPU cores to the chipset for locked instructions like TAS, CAS and CAS2 to work reliably as the AC68080 does. Do you consider this hardware support a hack/kludge that could aid in getting SMP working too?

No, I'd rather consider it just a desperate tentative, since it's impossible to add SMP to the Amiga OS AND keeping backward-compatibility with the existing applications.

That's why I've written several times TRYING/TRY before: you can try whatever you want, but your dream will remain a dream.
Quote:

cdimauro Quote: As already discussed, the 68k have already "SMP" support since the 68000, thanks to the TAS instruction, which allows to implement some simple locking primitives (in hardware). The 68020 added CAS and CAS2 to make it more easy to implement some more advanced locking primitives. So, the problem isn't about the 68k processor family which is lacking something which prevents OSes to implement the SMP, rather trying to support only Amiga OS because, as it was designed, it can't do it. Am I wrong? TAS alone was lame for multiprocessing support which is likely why the Amiga developers did not consider the loss of it due to how the Amiga chipset works as much of an issue.

Now you're starting a defamatory campaign against the 68000 processor only to justify (!) the Very Bad Work which the Amiga OS developers have done regarding multiprocessing (which SMP is part of).

In fact, TAS wasn't "lame": it was the minimal instruction / mechanism needed to implement locks with hardware support. Of course, it was not enough to implement more advanced locking protocols, which required more work to be achieved. Nevertheless, it was there to serve the purpose.

Better nothing on 1978. Or, would have you better liked the LOCK prefix, like on the 8086 which was released just before?

Beside that, I don't think that the Amiga OS developers ever considered the TAS instruction to be "lame", since they have completely f@cked-up the OS with their Very Bad Decisions which completely crippled the OS evolution.

But even in the case that they have considered to introduce multiprocessing support, it would have been impossible without Fast Mem.
In fact, that's the real problem with the Amiga: most of the systems had only Chip Mem (or Slow Mem, which was even worse), where you CANNOT execute ANY instruction which locks the bus. CAS and CAS2 had exactly the same issue like TAS.

In short: it wasn't certainly TAS the problem, rather the Amiga OS and the Amiga hardware.
Quote:

The loss of CAS and CAS2 with a 68020 was a bigger deal but I can not say they should have foreseen the issue.

No? Really? Could you please tell me when the 68020 processor was released and when the Amiga 1000 was?

By comparing the two dates you can draw your conclusions...
Quote:

Semaphores and other locking means were added to the AmigaOS anyway although the work was not complete enough for multiprocessing.

See above: it was already too late because it was Very Badly Designed.

There was nothing that could have changed it, unless you want to completely break the backward-compatibility. Which you don't want, right?

Once the milk has been spilt, there is no way to repair the damage: you can only throw it away...
Quote:

AmigaOS 4 added mutexes and more locking support but still does not support SMP.

MorphOS as well. And AROS as well.

Do you think that all their developers were stupid, since nobody was able to achieve it, even after so long?

When will you face the reality and understand that SMP isn't possible because of the original design which was very very bad?

The question is very simple: either you keep backward-compatibility or you add the SMP. tertium non datur

No matter which kind of horrible hack you want to introduce to the entire SoC trying to add the SMP: it will NOT work!
Quote:

The 68020+ Mac OS uses CAS and CAS2 but does not even support preemptive multitasking. I believe it would be easier to get the 68k AmigaOS and QDOS with preemptive multitasking working with SMP than the 68020+ Mac OS using CAS and CAS2.

It's not easy for both, because both had their own issues regarding SMP.

MacOS had a common address space at the beginning of memory locations, which caused a lot of troubles.

Amiga OS... you already know it.

There's nothing that you can chance once you've took bad decisions, because they were hurting the evolution of the platform.

At a certain point in time it's better to leave the legacy as it is, and move to a new (but incompatible) platform.
Quote:

A working CAS and CAS2 with AmigaOS may allow semaphores, mutexes and locks to work without Forbid/Permit and Disable/Enable though (SignalSemaphores rely on Disable which depends on hardware support).

It will not work anyway.

Once an application has acquired the control of the system (via Forbid or Disable), then the system is gone if it does NOT releases it. In fact, there's no guarantee that the application is so kind to give the control back by calling the proper releasing API. Even because... the application can simply crash before doing it, leaving the system blocked. And you know how fragile is the Amiga platform, right?

The original sin is that it allowed ordinary applications to take control of the system and access its parts (which should have been private). And you cannot change anything now.
Quote:

A lowest common denominator 68000 AmigaOS ensures 68k AmigaOS SMP would never be a threat to PPC AmigaOS 4 without SMP.

It's not a threat simply because it's impossible. For all.
Quote:

An emulation only 68k virtual machine ensures 68k SMP will never happen also.

At least it can spawn multiple Amiga OS applications which can run in parallel, taking advantage of the many cores available. Not like full SMP, but running each application on one of the core is already a very big improvement.

And if the (local. To the specific application) "system" is down due to the above mess that could happen, all other applications can continue to run without problems.

That's something that you can't achieve on a real 68k system. Or on OS4, MorphOS, AROS, unless you implement the above virtualizer.
Quote:

I wish I had input from developers like Carl Sassenrath, Jason McMullan, etc. We have this huge retro 68k Amiga surge in popularity and Amiga development is practically dead, killed by Amiga IP squatters and thieves holding the Amiga hostage.

What they could say of different from what I've already reported? They can only confirm the very bad situation.

But if you feel more comfortable having their opinion (and here you can ask Hans, which is the only OS4 developer which is also an active user. For MorphOS there was itix, but I don't see him since long time), then go ahead: your delusion will just be delayed...
Quote:

cdimauro Quote: Besides that clarification, I would leave MEMF_SHARED for the same behavior as OS4, and introduce MEMF_ATOMIC for such automatic locking of all RMW instructions running on those pages. However, I think that this is overengineering, if the only purpose of such new mechanism is to lock any modification to the respective counters (bytes) for the Forbid/Permit and Enable/Disable APIs. If this is the case, then it's enough to introduce a couple of new registers which hold the address of such counters, which force a locked RMW cycle for the specific byte being modified. Another (byte) register controls which one of the two locations are being monitored. So, and only for the Amiga OS, the location of the two bytes are put on those two new registers, and the their respective bits set on the new monitor-enable register. And that's it: you don't have to introduce a big complication on the existing software and APIs. My MMU page attribute suggestion has dual use. 1. pages marked as shared change RMW to locked RMW memory accesses 2. SMP cores wait when accessing shared data during a Forbid on another core Other uses and optimizations are possible too as it is can be advantageous to know if code and data is shared.

I'm not aware of any algorithm that could make use of it, for solving specific problems. I mean, in general computer science literature.

From all architectures that I've studied nobody presented features like that.

I don't know all algorithms neither all architectures, of course, but if you have something to share I'd be interested in.

Anyway, both points can be covered as well with the two locations monitoring registers which I've proposed. Once set and enabled, all cores can use them to monitor and lock/serialize the access to the two (or even just one) memory locations, also blocking all other cores in the meanwhile.

But it doesn't solve problem, as I've said before.
Quote:

cdimauro Quote: If it had been possible, existing Amiga applications would already have been patched to change MEMF_PUBLIC to MEM_SHARED, so that MorphOS and AmigaOS4 could take full advantage of memory virtualisation and, above all, resource tracking. Most applications have no sources anymore (that's also the reason why AROS is the ugly duckling of the post-Amiga OSes: because it supports a very small software pool), and reverse-engineering the existing ones AND understanding how they used the memory which they allocate AND patching according their binaries is a Gargantuan task. That's also because many of them are written in C, and they allocate memory using C's malloc(), which by default sets MEMF_PUBLIC (to be 100% sure that it can be used for any scenario. Which makes sense), and here patching the binary isn't straightforward, at all! Problematic programs would be slower but would still work like MEMF_PUBLIC memory is disadvantaged vs MEMF_SHARED memory but still works. Memory flags are easy to change with sources and patching is not difficult although there are cases where memory may be used for multiple purposes as per your example.

As I've already said, most applications have no sources any more. Otherwise it would have been much easier to patch them to correctly use the proper memory flags, to better support OS4, MorphOS and AROS.

Reverse engineering them can also be a hard work. Not like games, but applications usually have much more code to be disassembled and understood.
Quote:

cdimauro Quote: See above: the problem isn't RISCs neither PowerPCs. The problem was/is AmigaOS, which was Broken-By-Design by the absurd decisions of its engineers, which crippled the platform since the very beginning, giving it no chance (at all!) to evolve according to the more modern needs. No sane OS should publicly expose its internals, and even more important was exposing APIs like Forbid/Permit, Disable/Enable (and I would put also Supervisor, at least) to the public. A properly written OS uses Getters, Setters, and Enumerators to fully control what the applications can do and carefully arbitrate how they access to sensible information (e.g.: the list of running tasks, the signals, the available memory, etc. etc. etc.). It's not the modern OSes which are bloated: it's AmigaOS which was written with feet by hackers who killed any possibility of its evolution. Now you want to dirty the processor architecture and introduce more complexity to the SoC solely to try to make up for their inability and bad design, solely to try (because that's all you can do. In fact, there is no guarantee of success in the endeavour) to modernise Amiga OS in SOME aspect. Do you think that it makes sense? Unix/Linux and Windows were worse OSs initially than the AmigaOS.

Worse? In which sense?
Quote:

They evolved tremendously while the AmigaOS has evolved minimally.

Maybe because the Amiga OS had the too much problematic issues which I've talked about?

Why Commodore was planning to use Windows NT for its future platform? That might be already a signal that the platform wasn't able to keep up with the more modern needs.
Quote:

Windows received hardware support from the x86(-64) architectures for compatibility as I described above.

See above: if you introduce a 64-bit architecture, it will be naturally incompatible with its previous one.

And what usually happens is that the new processor supports both execution modes: the new one and the old one.

Do you expect that the your 64-bit extension to 68k would be totally transparent compatible with the current one? I don't think so, right?
What would you do then? Only leave the 64-bit execution mode or support both to let the current/old code to run?
Quote:

Unix/Linux breaks compatibility and users are forces to recompile their software.

I think that you've not so much experience with Unixes, right? Because what you've reported is usually happening only with Linux, which has a completely different model compared to the other Unixes (the only thing which matters is source-level compatibility).

The normality is represented by stable API and ABI, and you don't need to always update / recompile the existing applications to be able to run them even on major OS releases.
Quote:

RISC architectures often remove hardware compatibility too like ARM 26-bit address space support, extended precision FPU (yes, early ARM FPUs were extended precision like 68k and x86 FPUs), AArch32 support in ARMv9, etc. https://www.riscosopen.org/wiki/documentation/show/Addressing the end-of-life of AArch32#TOC1 Quote: 1. Background The release in 2011 of architecture ARMv8 added a whole new instruction set called AArch64 with wider 64b register bank, and renamed what was previously referred to as the ARM instruction set (which RISC OS uses) as AArch32. The AArch64 instructions are not binary compatible with the older ones. Until very recently, the ARMv8 targets we would like RISC OS to support have fortunately still contained an implementation of AArch32 for backwards compatibility, allowing RISC OS to run and entirely ignoring the AArch64 aspects. As at 2020 it was becoming clear that Arm intended to wind down ARMv7 and earlier (fewer than 50% of the cores available to license would run that way) to focus on their ARMv8 offerings, of which many dropped AArch32 support entirely. In April 2021 the ARMv9 architecture was announced with AArch32 relegated to being a license option, in much the same way that 26 bit mode became an option in ARMv4 rarely taken up. At the end of September 2023, Raspberry Pi announced their new Raspberry Pi 5, with a 64-bit quad-core Arm Cortex-A76 processor. While this still supports 32 bit instructions, crucially only in ‘user’ mode. RISC OS makes heavy use of ‘supervisor’ mode, which this processor doesn’t implement. As such, there is no straightforward way to port RISC OS to the Pi 5. This proposal identifies aspects of RISC OS that will require attention in order to migrate away from AArch32, to help making design decisions, and ultimately a route to implementing changes to ensure there are chips in future to run on. Some people say ARM won but it is not the original ARM. The new ARM is becoming incompatible with the previous 3 ARM ISAs. Maybe ARM thinks it is necessary to eject their legacy support to better compete with x86-64 with their compatibility baggage. It may work for the embedded market but likely not for the desktop market where compatibility is as important as performance.

That's exactly the reason: ARM was primarily active on the embedded market, and only on the recent years its processors were being used on servers and desktop markets. However, the mobile market was also important to get a more stable architecture.

Anyway, ARM worked and works very differently from other, "desktop" / "servers" CPU vendors, because the company offered/offers plenty of options to the licensees of the architecture. It means that if you need to have more stable and backward-compatible processors, you can always acquire the needed base architecture and extensions to have it, and create your own custom processor.

You can even get a license only for the architecture, and completely recreate the microarchitecture as you want, with your customization.

To me it makes sense if ARM wants to focus only on AArch64, and stop the development of AArch32 and Thumb-2: the future is 32-bit, and the two legacy architectures are enough to cover markets where their compatibility is still necessary.
Quote:

I think the AmigaOS is not nearly as bad as you make it out to be. It is very good in some ways and was a compromise in other ways. It needs to evolve and I believe it is good enough to be worthwhile to evolve. It will not evolve without enough compatibility though. The once standard and backward compatible 68k AmigaOS is fracturing and dividing into incompatible camps. I do not see a problem with simple hardware support that retains the 68k AmigaOS standard and compatibility.

Highly questionable. As I've said, I've written an article covering all major issues of the Amiga OS which crippled its evolution.

SMP was just the most evident, simply because single core/thread execution is flattening since long time, and the only way to push on performance is to make use of (many) multiple cores. As it happened on other OSes, which took advantage of it.

I would like to see what other patches will you propose to (TRY, again) to fix all other issues...
Quote:

At first you said 68k Amiga SMP was not possible with software compatibility

Correct. And I've offered also the proof.
Quote:

and now you say it is a bad idea because the AmigaOS is "very badly designed" and "Broken-By-Design".

No, I've said that it doesn't make sense. And that's "simply" (!) because you can't fix those issues while keeping the backward-compatibility.
Quote:

I would like to hear more developer's opinions. I believe the 68k Amiga SMP efficiency with my ideas would be better than AROS x86-64 SMP efficiency and PPC AmigaOS 4 SMP efficiency if it was working and both of those are likely incompatible with existing software. I do not hear many devs saying it would not be worthwhile implementing SMP which it may be. At least if some existing software is compatible, I believe it is worthwhile to try to implement SMP.

Nobody of the AROS, MorphOS and OS4 camps were able to solve any of the problems, even after so long, and not because of incapable people or wrong/bad architectures used: it was solely because the OS was so badly designed that it's simply impossible. Even with any additional hardware patches that you could think about.

But, hey, do you know what? If you think differently then you can always prove that you can fix each issue, even inventing new features to be added to SoC.

BTW, I agree that SMP is certainly and absolutely not even worth, but even necessary to have.
Quote:

cdimauro Quote: It's just one byte added on rarely used instructions (e.g.: not relevant for the code density) and there's no decoding overhead (x86 processors can handle 2-3 prefixes without incurring in performance penalities). The performance overhead happens solely because of the instructions' implementation (which require more cycles due to the more complex logic). The lock overhead for x86(-64) is less than RISC due to locked RMW instructions but x86(-64) encodings are far from desirable.

The LOCK encoding (prefix) is always the same since the very beginning.

The problem is that it's a prefix, of course. But if you have to deal with prefixes anyway, then having one for locking instructions is certainly irrelevant.
Quote:

cdimauro Quote: A 68k OS, which is NOT Amiga OS, can implement a lightweight SMP without all the overcomplication required only to patch the horrible job which was made with the Amiga OS. So, the problem is solely the Amiga OS. Certainly not the 68k processors. Yes, 68k SMP may be possible with Linux using multiple CPUs already. Recompiling pre-SMP 68k Linux programs may be required though. Throw away compatibility and SMP is a lot easier.

That's only for Linux, as I've explained before. Other 68k OSes don't always need to recompile the existing applications (assuming that they have a good design. Which can said of Unixes, which didn't expose internal structures neither nasty APIs).
Quote:

cdimauro Quote: See above: all such failures are only caused by the Amiga OS which was very badly written. AROS and OS4 (and I assume the same is for MorhOS) tried, but they haven't succeed solely because of that. So, not because people aren't gifted-enough, neither because the architectures were bad: the only culprit of this situation is the team of engineers which have realized an OS which is Broken-By-Design for implementing many modern features. Now, and as I've said, you want to TRY to resolve this mess adding horrible patches to the SoC. Doesn't is sound similar to the horrible patch of x86 (286, 386, x86-64) or PowerPC (prefix...) processors? To me yes. And, frankly speaking (as usual!), I don't like it (as I don't like the horrible patch of AGA on ECS). Was the x86-64 ISA worse than staying with the Itanium or x86 ISA? Was AGA worse than staying with the ECS chipset?

If you've no alternatives, or the alternative is another bad design which is doomed to fail (Itanium), then the answer is obvious...
Quote:

At least you would make suggestions for better upgrades but you can not make a suggestion for better 68k SMP compatibility

Matt, what's not clear to you that even the first 68000 already offered support to implement multi processors / cores / SMP systems since day one (1978)?

What's not clear to you that if this isn't enough for some systems (Amiga OS for sure) is solely because of their bad design?

The querelle is certainly NOT about the 68k SMP: it's ONLY about the Amiga OS SMP support. And not only for the 68k: it's a general problem for ALL Amiga OS successors / reimplementations, despite of the processor architecture.
Quote:

other than to throw the "very badly designed" AmigaOS away.

I've not said that. I've said that it should be left as it is, running on a sandbox inside the new, modern-with-all-bells-and-whistles, Amiga-inspired OS.
Quote:

cdimauro Quote: So, from a generic 68k SoC with a small embedded FPGA to target multiple 68k systems, now the target become a 68k Amiga SoC with a large FPGA and SMP patches solely for the Amiga OS? Why? A large FPGA with multiple CPU cores is how a SoC ASIC is developed.

You don't need to always embed a large FPGA on an ASIC...
Quote:

SMP for the 68k AmigaOS with compatibility is not a requirement for multi-system retro 68k hardware as AMP is good enough but SMP is important to system value and future opportunities with more than 2 cores.

See above: you're asking for the impossible. Adding a patch with the illusion to have solved the problem. For a platform which remains without a future, since it's failing on several other areas (without solutions).
Quote:

cdimauro Quote: That's because of what I've explained above: Amiga OS was very badly designed by its engineers and this crippled the platform. This is the exactly the reason of the current situation. Now, do you think that adding dirty patches to a SoC/architecture exclusively for trying to fix the big mess that the Amiga OS engineers made could be classified as "innovation"? The camps breaking 68k Amiga compatibility should be able to add the necessary changes for SMP.

I want to see how: see above...
Quote:

They just break all their existing software and recompile but that misses the large retro 68k Amiga market and even the small PPC AmigaOS 4 market. Maybe it will work for AROS x86-64 or MorphOS x86-64/ARM but they will still miss the large retro 68k Amiga market. I believe for any Amiga product to succeed that it should target the large retro 68k Amiga market.

I agree, because that's only and most important thing which is left and customers are using.
Quote:

Simple hardware changes that could much improve value and preserve compatibility should be considered. What makes a hardware patch/change dirty? Being different than mainstream which would make the whole 68k Amiga a dirty patch?

No. It's dirty because:
- the 68k processors family has already offered support to multi processors / cores / SMP since the very beginning;
- you want to add such patches with the sole purpose of TRYING (without any hope, unfortunately) to help 68k OSes which were badly designed (since they are unable to take advantage of the existing TAS/CAS/CAS2);
- it can't be reused for anything else (e.g. no algorithms can take advantage of it).
Quote:

cdimauro Quote: This looks exactly like MacOS X "Tiger", where 32-bit applications were first-class citizens, and 64-bit applications were additional commodities can can only be used for calculations (because nothing else was available in this user space: no GUI, no drivers, etc.). A so limited system which was quickly phased out by the next, full 64 bit, OS version. There are different implementations and different 32-bit and 64-bit compatibilities of architectures. Maybe separate 32-bit and 64-bit AmigaOS versions with dual booting would be more optimal.

It'd be the only option...
Quote:

Maybe the 64-bit AmigaOS would drop 32-bit compatibility and add SMP with major AmigaOS changes.

That's certainly possible, but requires some work.
Quote:

Why are there not 2 versions of the PPC AmigaOS 4 with the 32-bit version without SMP for compatibility and a 64-bit version created with SMP and used for porting to other architectures? How many AmigaOS 4 users would use the SMP capable 64-bit AmigaOS with less software and no 68k emulation in the kernel?

Besides the lack of man-power to create a 64-bit OS, the major problem is represented by the lack of 68k applications support.

MorphOS and OS4 would not have been as successful as they are without the ability to run those applications, and in a transparent manner. AROS has remained the ugly duckling for this very reason.
Quote:

cdimauro Quote: As already suggested, the Amiga OS should run on a sandbox, whereas the new, Amiga-inspired, 64-bit OS will run everything else. The Amiga OS platform is too old and too badly designed: it's better to leave it as it is, because enhancing it and not moving to something new (like it happened to other mainstream OSes) would only means preventing (real) innovations. Let the Amiga platform die as it is, and think about the next big thing (which means: welcome to the modernity). I believe multiple options should be explored but major AmigaOS changes likely would result in a sandbox for old software. It would likely be possible to boot the old versions of the AmigaOS for better compatibility on the same hardware.

That's the only real possibility.
Quote:

cdimauro Quote: The problem is that even OS doesn't offer a good memory protection: it offers a very very limited one, due to the intrinsic very bad design inherited by the Amiga OS. I believe Commodore considered the lack of AmigaOS MMU use to be a very good design as they saved money by not providing 68k MMUs.

Well, it was good only because the lack of the MMU made the platform much cheaper.

They were so tightly attached to the money that they didn't even want to put a 68010 there, which costed just a little bit more of a 68000 (and it would have fixed some problems).
Quote:

Ironically, the bridgeboard could make use of a MMU for caches, 68030 accelerators used the MMU to fix a bug, the early Amiga 3000 used the MMU to protect the kickstart in memory and Enforcer made use of a MMU for debugging which also saved the system from crashing sometimes.

The problem isn't necessarily the lack of an MMU. In fact, you can have a good design even without requiring a MMU.

Paradoxically, Windows has had a good design since the very first version (same year as Amiga 1000 / OS 1.1), because it didn't expose internals neither made nasty APIs available to the public.
It had the right abstraction which allowed to either implement the internal APIs in 16-bit (Win16) and tunnelling the 32-bit ones (WIN32s. When they arrived with the 386 version), or viceversa (implemented in 32-bit and tunnelling the 16-bit ones. Like Windows NT did), without affecting the existing applications (either Win16 or Win32).
Quote:

cdimauro Quote: Right. But not a dynamic stack, unless you want to waste a lot of memory (space). The stack will still be limited to a certain size, set by the icon or the shell --> a very bad situation for applications. If stopping a program with a stack overflow is a "very bad situation", what do you call crashing?

Is it relevant in this context? I don't think so.

What's relevant is that Amiga OS applications are limited by a fixed stack size. And if they exceed it, then they can still continue to work without crashing, which is even much worse (it's much better to crash and signal that something bad happened), since those are the most challenging bugs to catch.
Quote:

A MMU may more easily provide stack extension where at least VBCC only exits with -stack-check for the AmigaOS. http://www.ibaug.de/vbcc/doc/vbcc.pdf Quote: -stack-check Insert code for dynamic stack checking/extending if the backend and the environment support this feature. ... If the -stack-check option is specified when compiling, the library will check for a stack overflow and abort the program, if the stack overflows. Note, however, that only code compiled with this option will be checked. Calls to libraries which have not been compiled with -stack-check or calls to OS function may cause a stack overflow which is not noticed. It may be possible to extend the stack without a MMU but would require careful coding.

Dropping A LOT the performance, unfortunately. AND requiring the instrumentation of ALL code, which is another problem.
Quote:

cdimauro Quote: No, the real problem is that the Amiga OS was very badly designed by hackers with their restricted mindset, which completely crippled the platform and its future innovation. If we've to talk about sabotage, then it's certainly coming from the original authors of the platform. Who followed was doomed by decisions that were made by others, and that cannot be fixed or overcome without compromising the existing software base (which is the only thing which is left... almost all in binary format -> very very difficult to fix). The AmigaOS "was very badly designed by hackers", even though it was better than most other OSs of the 1980s as I showed above,

Yes, from a user perspective. But paying a BIG price: its evolution.
Quote:

and fixing the hardware for compatibility is a dirty hack.

Absolutely. Even because it's useless: the issue will not be fixed.
Quote:

Windows using dirtier hardware hacks to maintain compatibility should have been thrown away too then

Which "hardware hacks"? There were none of them which Intel and/or AMD have introduced specifically for supporting Windows.

If you're referring to the ones that you've listed before, then I've already replied: they were no hacks.
Quote:

but instead it became the most popular desktop OS.

That was thanks to Gate's vision and ability.
Quote:

They should have made the necessary software changes breaking compatibility like Unix/Linux instead,

Nope. And see above for Unix/Linux.
Quote:

even though the lack of standardization only gained 4% of the desktop market despite Linux becoming free on the same x86(-64) hardware compared to Windows with 71% of the desktop market.

That's because Linux is too much fragmented and without stable API/ABI, which is a requirement on the desktop market. Linux is still lagging on that, despite it's the foundation of Android.

Anyway, and to close this long message (which took me a lot), I understand your wishes, but you're taking it too much personal and... like religion. In fact, you reported wrong information and trying to change the focus of the discussion only to advocate your dream. Technical things and History can't and shouldn't be manipulated, distorted, or even mocked for this alone. This doesn't work, because what should always matter are the FACTs.

@kolla

Quote:

kolla wrote: @cdimauro Quote: kolla might know which ones. Yeah, they can be summed up as “some atari ST games�. I don’t know of any Amiga game or software that require “cycle exact� CPU… heck, not like one 68000 is “cycle exact� to the next one, from what I’ve gathered there’s variety between the various 68000 variants.

Are you sure? I recall that some games needed a 68000 cycle-exact because they were starting a Blitter operation, and after that they started the next one in some cycles because they were sure that enough time was passed by executing precise instructions. And the ST had no Blitter...

@cdimauro

I’m not one who spend a lo of time with games, others would know better. All I can say is that cycle-exact appears to have been much more important to the Atari folks. One thing is when a game runs too fast on fully 32bit 68030 based A3000, another thing when software doesn’t run at all because timings fail on an non-exact 68000 clone.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC