I guess if we go that far, one could even implement the equivalent of PAE to get access to even more RAM, like how Pentium Pro and newer Intel CPUs can access up to 64 gigs of RAM even though the instruction set is 32 bit only.

That wouldn't be a problem, the upper 2 GB would be available to programs, they just wouldn't be managed by the OS. E.g. you couldn't allocate memory in those memory regions through the OS but you could address it. So if your program uses some portion of RAM in the upper 2 GB and so does another, you would be bound for problems.

Keep in mind, use only as fastRAM. ;)

Indeed. I would prefer running a second AOS instance in the upper 2 GB and using an MMU to change the virtual address space of that instance to the lower physical 2 GB. This would also work for more than 4 GB physical RAM. But that wasn't the question.

This will give us 3 types of ram/speed:
Fast
Chip
CacheRam

This gives the programmer full control of the hardware. What do you think?

Cleanest solution is just to patch exec for the extra RAM and at the same time we should look beyond this.
And i do not mean a MMU. ;)

I think such hardware features should be transparent because it couldn't be taken for granted that future hardware would have this feature. The distinction between chipmem and fastmem is necessary because only one of the two can be accessed by the custom chips. Apart from that, mem should just be mem to any program.

Just my humble opinion, of course.

Would it ever be possible that there was an assembler routine made that all could agree with to the way RAM above 2 Gigs to 4 could be used? Tall order I suppose.

I ask because clearly the way DATA has exploded that Amiga does need a way for it to be accessed in short order.

We have the BEST HW/SW combo bar none, but it needs a boost.

Probably the best solution for the time being would be to have a new ramdisk device that can be used to open/create large files. Perhaps these files could be made to be directly accessible using pointers. This would have the downside of limiting the total RAM size to 4 GB because of the 32 bit limitation. If the ramdisk was accessed just like an ordinary filesystem, it could have any size.

Another idea would be to use the additional RAM as part of a virtual memory subsystem. This would require an MMU, though.

The MMU would also be the only clean way to break the 4 GB barrier. The MMU could be implemented to manage more than 4 GB of RAM while limiting the address space of each program to a maximum of 4 GB (or 2 GB).

to quote RJ Mical, "Several reasons. Obviously, cost was a factor. MMUs available at the time the Amiga was designed also consumed system time [this is what he said- I'm just the scribe]; although newer MMUs solve this problem they were too late for the Amiga. Second, the original goal of the Amiga was to be a killer game machine with easy low-level access, and an MMU didn't seem necessary for a game machine. Third [get this!] with an MMU, message-passing becomes MUCH MUCH hairier and slower, since in the Amiga messages are passed by just passing a pointer to someone else's memory. With protection, either public memory would need to be done and system calls issued to allocate it, etc., or the entire message would have to be passed. Yecch. So the lack of MMU actually speeds up the basic operation of the Amiga several fold.".

source: EXTERNAL LINK

Yes, that is true. The AOS message system is mostly incompatible with individual address spaces for individual tasks. The AOS message system could be implemented to work in a memory managed environment without the tasks noticing. What would never work, though, is to make sure that the data passed from task to task is still valid in a different address space (i.e. when passing pointers, as you say). I wrote an AOS compliant demo engine where the code was split into demo code (client) and a server that made sure that the frame was displayed (custom chunky2planar or via RTG according to what was available). Because of the size limitation of AOS messages I passed pointers rather than the image buffer itself. This would break if the two tasks resided in different address spaces.

Regarding RJ Mical's comment, all of that was the (completely valid) point of view of 1985. Today the message passing would hardly be a noticeable speed penalty.

I think that we could implement some (somewhat restricted, sure) memory protection in alternative implementation of AOS (AROS?), namely we could map memory regions as shared between these processes that communicates with AOS messaging system. What you think?