How to move AROS forward

[SamuraiCrow]

Regarding memory protection:

1. Can it be done?
2. Can it be done elegantly?
3. Should it be done?

1.  It can only be done part way and it requires an MMU.
2.  No, managed code is much more elegant even if it is sometimes a bit slow.
3.  No.  If we are going to support the Natami and MiniMig as a starting place, we're going to have to realize that the fact that the 68070 on the production Natami and 68000 on the MiniMig will not have an MMU is going to prevent a memory-protected AROS from running at all!

There are so many things that should be done first:

1.  Standard Template Library for C++ code.  This can be implemented using STLPort.
2.  Expand the runtime library to do STL functions in a memory-efficient manner.  This can be implemented through template specialization.
3.  Minimal bytecode as a distribution medium for code across all of the supported hardware platforms.  (Possibly even portable to all of the OSs that support AmigaOS 3.1 APIs.)  Tough one but but I favor LLVM to implement this.
4.  Compiler to generate code in that bytecode.  LLVM-GCC does this but is difficult to build.  The upcoming Clang project on the Mac might someday be a better choice though.
5.  Entry level programming languages.  Another tough one but I'm already working on this one.  Hollywood also works for this one.

[SamuraiCrow]

@HenryCase

Any time you see a structure being passed into a system function with an &structurename in C code, it is passing a pointer to an internal stucture in the application's memory to the operating system.  More importantly, if the operating system allocated the memory and passed back the pointer, the operating system would be the owner of that memory and would have to "change ownership" to the application and "change ownership" back to the operating system every time a pointer was passed back to it.  That would be a glacially slow operation.

I think the answer to the issues that are often associated with memory protection are generally better addressed by using "safe" programming languages like Oberon and some versions of Basic that either don't directly support pointers in general, or have tight limitations on the use of arrays and other data structures to monitor them for overruns and NULL pointer values internally.

[SamuraiCrow]

Hans_ wrote:
@SamuraiCrow

I think the answer to the issues that are often associated with memory protection are generally better addressed by using "safe" programming languages like Oberon and some versions of Basic that either don't directly support pointers in general, or have tight limitations on the use of arrays and other data structures to monitor them for overruns and NULL pointer values internally.

The problem with that is that it requires all software to play by the rules. Malicious code does not. Memory protection helps prevent malicious code from doing harm by restricting access to resources.

Hans

Memory protection doesn't stop malicious code either.  In a black-box operating system malicious code can overwrite anything that is in the same memory page as it is.  In a white-box operating system it can corrupt any system that the code has access to.

The problem with memory protection is that it is limited to memory granularity of the page size of the MMU which is usually 4k.  If the assign command is only a couple hundred bytes long and you add memory protection to it it becomes 4k for the code, 4k for the stack, and 4k for any global data.  That's 12k for the smallest program to run.  That eliminates all of the streamlined efficiency of the AmigaOS when it needs more memory than it allocates just to run a small command.

[SamuraiCrow]

@HenryCase

To scan for those binary equivalents you'd have to know the difference between code and data.  If you write a patcher to go through and change all of the binary instances of memory access outside the main chunk of code, you'd probably end up inadvertently changing some constant data to something different.  In short you'd have to go into every program by hand and write patch code for every instance of pointer access.

Why not just get the source codes of everything you'd ever want to run on AROS and recompile it for MacOSX?  You'd save yourself a lot of headaches and the rest of us a lot of hassle. :-x

[SamuraiCrow]

@HenryCase

In a 68k instruction set (as well as the x86), there are variable widths for instructions to have.  This would make PowerPC much easier since all of its instructions are the same length.

[SamuraiCrow]

Being designed for a 16-bit bus, the 68000 has only 16-bit multiples in its instruction set.  That makes all of the opcodes either 16,32,48 or 64-bit sizes.  No 8-bit opcodes, in fact, word misalignment will cause a lock up on 68000 series processors.

[SamuraiCrow]

The port of SDL to AROS is rather old but it works for some things.  Also, Origyn Web Browser has been ported to AmigaOS 3 and 4 but the license isn't listed in the article.  The OS 3 port might work on a hefty AROS box if Joerg is required to hand out the source.

As for Wanderer, Rob had some emotional problems to work out so he ducked out of the bounty.  The bounty is valid again if you want to take it.

[SamuraiCrow]

Update:  It's BSD Licensed but Joerg said he would post the changes needed to make an OS4 version on the Sand-Labs Subversion server when he's done with the latest version.