In my opinion the MMU could be used to sort of virtualise AOS. As everybody knows, it wouldn't be easy to add memory protection to AOS where programs access all sorts of public and other tasks' private data structures. However, considering that AOS can run in 1 or 2 MB of RAM, using an MMU it should be possible to set up a corresponding address space for each program with an AOS instance for each task or user program and protect this address space from other such address spaces. You would always get a pristine copy of AOS for your program and if you mess up any of the public structures, well, it will only be your code that crashes because of this. Of course, all of this could only be done in an open source implementation of AOS because unless you want to fully virtualise everything (which would require a hypervisor) you will somehow have to merge input and output data. For instance all AOS devices would have to be split into a client-server architecture where the devices of the local AOS instance are the clients of a server device which resides outside of the local OS instances. Intuition windows would have to be collected on a single (workbench) screen and task communication (AREXX comes to mind) would be a big issue.

I know that this currently appears to be an impossible endeavour and there will probably be far bigger technical obstacles than I can think of but I like thinking about how this could be a way to move AOS to the whole new world of memory protected OSs while maintaining OS compatibility even on the binary level.

A MMU has several main tasks, Virtualization requires a MMU for the simple reason you envelope your program inside a memory space.
This for a x86 system was a gain because they didn't had a flat memory layout no they had obstacles to overcome adding a MMU to the system made it a option for the x86 to use a flat memory map like the 68K.
Spreading it all over the physical memory map.
The advantage of a MMU is none in this case for a 68K system.

On a 68K we have something called PIC, which makes it very easy translates to a programmer to make a program that behaves according to that part of the MMU requirements.(no gain, big loss)

Second the reason AOS programs are small is because of shared libraries, one copy of a library exist when needed in memory during runtime.
Your proposal makes using libraries the Amiga way impossible since it would increase the memory requirements exponentially.(keeping several copies of the same data in memory)

Your last proposal makes me think about the X-windows system which makes my head hurts.

All you said is possible, it's just not feasible for the losses outweigh the gains made by doing it in said manner.

Why would that be? Libraries do not require write accesses. Shouldn't it be possible to map the same portion of RAM holding the library to multiple address rooms? UNIX has shared libraries and memory protection after all. AFAIK in UNIX every process communication requires a copy of the transmitted data to be passed to the recipient process. However, this is implemented by some MMU magic and only if a write access occurs will the corresponding page be copied to a new portion of RAM. I don't know much about MMU programming but I don't see why something similar shouldn't be possible for shared libraries (one physical instance - many virtual instances).

AOS != Unix

A truely brilliant remark. The MMU doesn't stop being capable of doing things it does under UNIX once you load AOS, does it? The point was that your only argument against my proposal does not appear very convincing because having multiple OS instances of one and the same OS doesn't necessarily mean that you have to spend additional RAM space for multiple instances of the same shared libraries.

I nowhere said that all of this should be possible without any changes to AOS. I explicitly mentioned an open source implementation of AOS (read AROS). Obviously the hypervisor-AOS managing the AOS-instances would have to be something entirely new. This hypervisor-AOS would have to contain all the server parts of all processes that are part of the OS (especially devices) and the window management. Since you mention X: the fact that X can give a lot of headaches, does not mean that it doesn't have a lot of power, too. Indeed splitting Inuition into a client-server structure would make display redirection simple.

Just put execbase at some address other than 4, reserve a bunch of memory for that particular instance of the OS, and let it run there for a while. Of course, the processes would have to be well behaved and not try to go outside their memory or use the wrong execbase.

If you had more cores (which do not need MMU either) you could put each core to work on their own memory and their own exec.

It's possible you don't even need to change execbase.

I am not sure this is the route I would take, but not impossible at all in my humble opinion.  I would use extra cores for some more dedicated parallel programming. (Sort of "CUDA" style, but not CUDA itself.)

True, but there is one fundamental weakness: execbase is hardcoded in almost any piece of AOS user software. Usually you just do a "move.l 4.w, a6" in order to load execbase.

If all software were well-behaved, you wouldn't need any memory protection at all. I am a big fan of memory protection because it is so much nicer to not crash the whole system if something goes wrong. Security aspects are also important in a modern computer system. MacOS somehow made the progress from 68k without MMU to a modern day OS, UNIX has always had memory protection and memory protection was one of the few advantages of x86-based systems in a long time.

Natami is about what Amiga could have become if it had continued to be developed. Memory protection would have become an important issue in the mid-90s. So I think it seems very reasonable to spend some thought on how Commodore could have addressed this problem in the most elegant way.

But besides that.

In a ideal world the MMU is a redundant piece of hardware.
Sadly enough we do not live in a ideal world we have programmers guessing what their code does, there are oversights on typo's in the code.
And then there is malicious intent, I will not go not into that here.

My downright point why not to have a MMU is because it doesn't like DMA's.
When we could DMA in a memory segment in that same segment we cannot apply our MMU.

Using a PIC programming style you don't need a MMU, since it's style enforced, It can however still help.

the Irony of it all is usually a MMU to keep users and programmers a like out of a place where they shouldn't be in most cases.(hardware registers of a chipset)
On a Amiga these systems are the very one each game uses as a API.

In the Amiga DMA only happens in chipmem. All programs and data would reside in fastmem and chipmem could be accessible for all software (simple solution). Or any access to chipmem could be trapped and handled separately (difficult solution).

the Irony of it all is usually a MMU to keep users and programmers a like out of a place where they shouldn't be in most cases.(hardware registers of a chipset) On a Amiga these systems are the very one each game uses as a API.

Amiga games are all but AOS software. The problem about accessing hardware registers is an old one and will not be solved without emulation of some kind. However, AOS-compliant software never needed to access the hardware registers (at least starting from AOS 3.0). Some time around 1995 I wrote a small tech demo for a 2D parallax scrolling jump'n'run that was 100% AOS-compliant. Such software would continue to work even if all direct access to the chip registers was barred. And so would all types of productivity software.

I'm against anything causing bloatware to come to Amiga (virtualization, for instance).

I'm against multi-user and login protocols.

I'm against hardware abstraction layers.

I'm against "the registry".

Keep it simple and weed out the programs that aren't written well enough to work in a "fly by the seat of your pants" near real time OS that gives as few barriers as possible for one to do their computing on.... THE last Personal Computer.

AOS/Amiga and NatAmi!

I guess what we're learning here is that nobody really cares.

your first point is not completely valid.
for one you still need to wait for disk access.
second accessing chipmem in which the complete OS can reside cannot be guarded by a MMU.
Chip Set Registers cannot be protected by the MMU.

your second point, Writing a ExoKernel can abstract the system enough to run multiple instances of AOS next to each other unaware of the real hardware.

Your 3rd point, it has his place.

your 4th point, Above mentioned ExoKernel could handle it.

5th is a rather pointless one, never heard of a amiga with a registry file.

I would have to say for a development system a MMU is a good help debugging and all.
On a user system it is less valid.

There is a difference between a production system and a home system, i am willing to discuss about it but in another thread please.

Nixus Minimax wrote:

You would always get a pristine copy of AOS for your program and if you mess up any of the public structures, well, it will only be your code that crashes because of this.

The problem here is, of course, that there need to be some interface functions to render several programs on the same screen. This is typically done graphically by layers, by graphics and by intuition. It also means that the public data visible through these functions would have to be "fakes". So for example, under AOS, a program can get a list of layers on a screen, and then "steal" a layer of a second program. Under such virtualized Os, a "layers.library" would still need to be there, but there would need to be a "fake" virtual part for each program that does nothing but pretend to the program that there are layers, namely only its own, and a real "manager" that does something like layers, but in a protected address space that does not allow programs to read or browse it. It also means that the "real screen" memory must not be readable, but somehow "there" for such virtualized programs to pretend that there is screen memory.

Nixus Minimax wrote:

Of course, all of this could only be done in an open source implementation of AOS because unless you want to fully virtualise everything (which would require a hypervisor) you will somehow have to merge input and output data. For instance all AOS devices would have to be split into a client-server architecture where the devices of the local AOS instance are the clients of a server device which resides outside of the local OS instances. Intuition windows would have to be collected on a single (workbench) screen and task communication (AREXX comes to mind) would be a big issue.

Yes, yes, and yes. It means that everything a program uses today to communicate with the Os would be end-points of services that communicate to an interface layer, which talks to the VM manager in some protected way.
 

Nixus Minimax wrote:

I know that this currently appears to be an impossible endeavour and there will probably be far bigger technical obstacles than I can think of but I like thinking about how this could be a way to move AOS to the whole new world of memory protected OSs while maintaining OS compatibility even on the binary level.

As you say, in *principle* something like this is possible. It is possible on the PC, for example, and then called "a virtual machine". With a proper VM, you can get your "windows windows" on an X screen. [And this is not science fiction. Most of our machines in our computing center *are* actually virtual machines, which makes a lot of things easier for us.]

So long,
Thomas

I'm not sure whose points you are discussing but I'll answer anyway.

second accessing chipmem in which the complete OS can reside cannot be guarded by a MMU.

Why not? Chipmem also has a physical address assigned. Furthermore AOS can be placed in chipmem but it need not be so. It can run perfectly without any portion of it placed in chipmem other than gfx and sound data. In fact it does so as long as fastmem is still available.

Chip Set Registers cannot be protected by the MMU.

Same as above. They can. Not with AOS as it is now because AOS would have to be aware of the protection and would probably have to turn it on and off as required when itself accesses the registers. Protecting the chipset registers undoubtedly would break a lot of Amiga software. However, this software is NOT AOS-compliant software. AOS offered means of doing everything via OS-functions. Of course the copper could continue to write to chip registers without the MMU every taking notice of it. However, the copper list would be set up by the operatings system.

EDIT: speaking of virtual machines, the abstraction would also be neat for switching CPUs. Everything inside the AOS-instance runs as a task on an emulated M68k, everything hosting the AOS-instances would run on a real CPU with a different ISA.

His last point was rather moot.

I said can didn't?
It could reside in Chipmem it not needs to be but it could!
A MMU cannot guard the Chipmem because it get accessed by the chipset and thus cannot be trusted for use with a MMU.

And again your wrong chipset registers are self modifying and thus cannot be trusted by a MMU.

To allow a MMU to function properly one would need to disable the DMAC.(Angus and all of it's 25 DMA channels)
you should remove things like the Copper and it's danger mode.
The Blitter would have to get crippled since hey guess what it is not allowed to write to Chipmem. ;)
The list goes on and on it's not really a problem one could solve with software, it's a hardware feature. :P

You can write a complete 'NEW' OS for the Amiga and still you cannot protect the Chipmem with a MMU.

It would break compatibility period, and that happens to be one of the main goals of this project.

I am not saying it's perfect, but it's good enough to my standards.
When debugging i would miss a real MMU but besides that i can live without.

1. A MMU would create latency even when not used, and overhead when it is.(most of a MMU's latency is hidden in memory access)
2. Even if a MMU is used, it does not guaranty the system won't crash one's in a while.
3. A MMU requires a slice of memory for it to maintain pages, on a 68K system, when that part of memory is accessed by a DMA device chances are the data found there has become corrupted.
4. in allows lazy men coding, because the MMU would save their 'behinds' if something went wrong.

I am of the opinion we should build a machine for proper coding not sloppy coding.
I know we all are lazy, but if our program doesn't behave we should fix it, or would you disagree?
If you would follow the proper procedures on a amiga your programs would work without the use of a MMU, or need to use a MMU.
Like I said earlier we have PIC programs on the Amiga.(Placement Independent Code)
That is just about 90 percent of what a MMU does right there!(we don't need no TLB's, more buffers for through put)

We need as much as we can get out of the FPGA, if this were a ASIC and we had the die space for it who am i to argue?
But this is a FPGA, we have a limited amount of resources in the chip, There is no point in slowing the system down to a grinding halt just for memory protection.

What is the problem with not having AOS in chipmem anymore? We neither have new chipmem-only machines nor do we need to make this new OS approach run on classic Amigas with MMU but without fastmem (I doubt there are any!). We are talking Natami here.

A MMU cannot guard the Chipmem because it get accessed by the chipset and thus cannot be trusted for use with a MMU.

I think you are mixing up memory protection with topics such as cache coherency and the like. The chipset can access chipmem without the CPU and MMU taking notice. No part of AOS relies on the chipmem having the same content all the time.

What do you think happens with a standard graphic card's internal memory? It gets written to all the time by the graphics chip. Nonetheless the physical address space is protected by the OS so that it cannot be accessed by user programs but only by OS functions.

3. A MMU requires a slice of memory for it to maintain pages, on a 68K system, when that part of memory is accessed by a DMA device chances are the data found there has become corrupted.

How would any DMA device write over the OSs memory page management? The OS resides in ROM and fastmem, remember? And even if not: any DMA would be set up by the operating system. If the OS is buggy and corrupts its own data, well yes, it will crash. We all know Windows bluescreens and Linux kernel oopses.

I know we all are lazy, but if our program doesn't behave we should fix it, or would you disagree?

I do agree but it would be nice to not always have to watch the whole system reboot, wouldn't it? In addition I am aware of the fact that you never can test all possible scenarios and accordingly there is no perfect code. Your argument is like saying that you know how to drive and accordingly do not need airbags nor safety belts and people who want that type of stuff should learn how to drive in the first place.

Like I said earlier we have PIC programs on the Amiga.(Placement Independent Code) That is just about 90 percent of what a MMU does right there!

Seriously, I don't see what relocatable code and MMUs have to do with each other.

We need as much as we can get out of the FPGA, if this were a ASIC and we had the die space for it who am i to argue?   But this is a FPGA, we have a limited amount of resources in the chip, There is no point in slowing the system down to a grinding halt just for memory protection.

So now it is only a question of feasability? The developer's comments on the subject of MMUs I read did not mention that AFAIR. They merely stated that there was no apparent advantage of implementing one because there seemed to be no use for an MMU.

BTW, I worked with UNIX systems that ran on ordinary 68030s with MMU and had screen resolutions of 1280x1024. They were not blindingly fast but they sure were stable and much better to work with than any Amiga I ever saw. The 050 or 070 should be much faster than both a 68k-based UNIX workstation and any classic Amiga even with MMU support.

There wouldn't be much more software that will break because the problem is comparable with the leap from ECS to AGA systems.

Using a GFX in a example do it properly you forgot the driver layer between the OS and the Hardware.

In the past Gunnar proposed to allow the blitter to do copy mem operations between fast and chip because it was faster then the CPU.
The problem isn't with the DMA devices specific, it is that every decent programmer knows how to use them, and does use them without notice of the OS.
This is a coding style problem because the Amiga Chipset is the API, you can jump high or low it is this way you can say the OS gives a extra layer, but this was too little too late.(RTG, anyone?)

Ah, yes I would agree that it is nice not to have to go through reboot on each error.
I also agree not Every possible situation can not be tested without sending a few out in the field for trial.(some bugs takes years to even occur)
But i do not agree we should not aim for bug free code while we should.
It is not a commercial project thus they have the time to do and get things right.(this is something that has been lost on the PC end it no longer goes about quality)

And dude, if you wanted virtual addressing you should know what a TLB does.
PIC is in my opinion the software equivalent of virtual memory without MMU hoops to jump through.(I know i am not completely right, but hey it is faster then said hardware solution)

Much better to work with than any Amiga did you ever saw, so your are saying you never saw a A3000UX running?(sorry had to ask)
Back to the point, I am not a team member Nixus i am a luser just like you.
As for about feasibility, i mentioned all the reasons why not to have a MMU in my previous posts.
Besides that IMHO a user doesn't need a MMU if the programs behaved well, like i said in a ideal world there is no need for a MMU.

Hm, about the 050 last i heard it was still being optimized, besides that there are some cheats like a CyberstormPPC which in some cases have a edge on the 050 because the 050 is not super scalar.(You said 68K workstations and made a assumption that all Amiga's were 68K systems)

It still doesn't change the fact that a MMU isn't needed, it isn't vital to the system operating.

No, it is not, you make that up. Read the Natami Home Page. It clearly states:

"The basic concept is straight: Get the original Amiga design up-to-date.

The NatAmi approach is to rebuild the original system

    without emulation

    without abstraction layers

    without legacy drawbacks"

The problem isn't with the DMA devices specific, it is that every decent programmer knows how to use them, and does use them without notice of the OS.

In my opinion that is quite the opposite of a decent programmer. A decent programmer knows that Commodore never endorsed register banging and made a lot of efforts to provide alternatives via AOS, especially with AOS3. I am not aware of a single hardware-related thing you can do accessing the chip registers directly that you cannot do via AOS function calls. On a 68000 the processing time probably counted but Natami is about an up-to-date-Amiga (see above) with far more computing power.

But i do not agree we should not aim for bug free code while we should.

Could you show me where I said that?

And dude, if you wanted virtual addressing you should know what a TLB does.

I happen to know that. I'm under the impression that you don't. A TLB is simply a cache for page entries that assign virtual addresses to physical addresses and vice versa.

PIC is in my opinion the software equivalent of virtual memory without MMU hoops to jump through.

Oh, is it? I didn't know you could access Amiga harddisks using 32-bit pointers in processor registers. Really, this discussion is bizarre. Your point that you despise MMUs and their functionality and only want a super-speedy Amiga that hasn't improved in any other way than hardware-wise has come across.

Much better to work with than any Amiga did you ever saw, so your are saying you never saw a A3000UX running?(sorry had to ask)

No, I never did. Why would that be so much better than other UNIX systems with 68030? You are aware that the A3000UX had an MMU and memory protection, are you? Otherwise it wouldn't have been able to run UNIX.

Besides that IMHO a user doesn't need a MMU if the programs behaved well, like i said in a ideal world there is no need for a MMU.

Yes, in an ideal world there is no need for safety belts. I think there isn't more to say about this.

CyberstormPPC which in some cases have a edge on the 050 because the 050 is not super scalar.(You said 68K workstations and made a assumption that all Amiga's were 68K systems)

Where did I do so? I explicitly wrote "classic Amiga" in this context. Frankly, I don't care about PPC add-ons and I am pretty sure hardly anybody here does. Commodore did not go the PPC-route, 3rd party providers did once they could not offer anything beyond an 68060.

BTW, I'm not 100% sure whether I ever saw a PPC Amiga. I believe I saw one at a convention but perhaps I'm mistaken and it was only an 060.

It still doesn't change the fact that a MMU isn't needed, it isn't vital to the system operating.

Who needs an Amiga anyway?

Define "lot of efforts".  After having tried my best to make Copper-lists work in a reasonable fashion as a simulator on ordinary PC hardware, I can tell you with certainty that Commodore's efforts were mere window-dressing and without hardware-banging the Amiga wouldn't have dazzled anyone.

Trying to write an impressive Amiga game without Copper-lists (which bang the hardware a lot) would be like trying to write Doom 3 or Quake 4 without pixel-shaders.  Banging the hardware is a requirement for the NatAmi.  Otherwise we wouldn't be able to run 80% of the software and wouldn't be considered an Amiga-compatible legally.

I'm giving some hard thought to making new OS APIs for AROS 68k explicitly for the NatAmi drivers.  This should allow the Copper coprocessor to be accessed like the pixel-shader hardware on GLSL, only without floating point getting in the way.

BTW, the reason we're not putting an MMU in the NatAmi is mainly because there isn't room for one.  If you want an MMU, you'll have to buy a 68060 daughterboard.  The N68050 will not have an MMU.  Period.