AROS Hits the Papers.

[Crumb]

"Im sorry but as we have probably stated a zillion times its quite hard implementing a 68k emulator in the same way as on MOS/OS4 in fact if we do it will dragg down the whole OS performance (on x86) and thats NOT AN OPTION (at least in my eyes)! then we should also add that there is starting to be quite vocal requests for MP and other things its impossile to add without breaking compatibility with AmigaOS! you just cant have it all im afraid."

I don't agree. You could split the ram in two sections using the MMU. The 68k programs would be put in one memory space and all accesses from 68k would be converted to little-endian and the accesses from x86 software to 68k modules as the 68k modules/programs would be in the "68k memory space" would simply convert the addresses.

That wouldn't slow down aros unless you use 68k programs/libs/etc and that wouldn't change much the design.

OS4 has done that and it's the most portable solution to emulate 68k on x86 IMHO. You should finish your MMU.hidd first, of course.

And I prefer native programs too, but I prefer programs that no programs at all.

The idea of using an UAE with a rom that calls directly to AROS functions sounds well the first time you hear it, but later you realize that you won't be able to use 68k libraries on AROS, so it's not a good solution.

[Crumb]

@Bloodline:
"I have no idea how one could actually do that... Why don't you build an emulator as you've described so that we can see it."

Firstly I would need an MMU.hidd. ;-)

And later AROS would need virtual addressing to make it work efficiently, otherwise we would have to reserve the memory of each cpu zone

@falemagna:
Of course OS4 (I ommit the "A" because it is THE AmigaOS) doesn't need to switch words, it's running on a big-endian cpu so no need to do that...
If you have the x86 and the 68k data long-word aligned you could do it this way:

|0A|0B|0C|0D| addresses-> 01,02,03,04

if I wanted to read the 2nd byte from the little endian ram zone the first thing I would do is to check what byte of the longword would it be part of...

if the byte is in the address from 01-04 it is part of the first longword, if the byte is in the address 05-08 etc...

so we read the address 02 and it's detected that it's part of the first longword, so we flip the bytes and we read 0C. If we read the third byte we read 0B, if we read the 4th, 0A. So now we have in the 680x0 memory area:
0D|0C|0B|0A

if the x86 native program tries to access some bytes, as the memory will be aligned we will choose the right byte thanks to the memory alignment.

So basicly we would check ALL the accesses to memory and we would byteswap absolutly everything.

In conclusion:
-we have an MMU to mark one zone as 68k and other as x86 (that would require MMU.hidd to work, and virtual addressing activated to be efficient and to avoid wasting too much memory)
-we have everything long-word aligned (more or less easy)
-we determine if a byte is part of one longword or part of the next one (a bit slow, I know)
-we swap the bytes to copy the right one to the different memory areas (680x0 and x86)


I said that it was similar to the OS4 approach only because they also split the memory in two parts, the 680x0 zone and the x86 zone.

BTW, I've translated the AROS introduction to Spanish, where should I send it?

-edit-
I've read the other comment later...
"what if the data is NOT in litte-endian mode, but it's just text being copied from one memory location to another? You see, it doesn't work. "

mmm If I read a text in a little-endian machine, wouldn't it be stored this way?:

Original text: "THIS_IS_TEXT"

1st longword: SIHT
2nd longword: _SI_
3rd longword: TXET

Then it would be copied correctly to the 680x0 memory area swapping the bytes just like in the other situation

[Crumb]

"This is a requirement impossible to meet"

You could force your malloc() function to always align the data. Don't tell me that aligning the data is impossible because powerUP aligned ppc exes for example...

about knowing the data type... yes, I've thinked about it and it would be impossible or almost impossible...

lets say we use two bytes to store a number and then 4 bytes to store a little text. We would have:

12TEXT...

yes... even if we aligned the stuff it would be impossible... you are right. Thank you Fabio :-)

but...

That leaves me with only one idea (/doubt), using the 68k memory area as the guy who did executor (a mac emu). He used memory in the oposite order...

....TXET21

if we wanted to read the first two bytes we would only have to substract the offset of the address we want to access to the end of the memory to access to the right position.

If we wanted to access an entire word from the 3rd postition the cpu would read it correctly as the order of memory is opposite

mmm what do you think about this? The 68k emu may have to be changed...

but this should work...

[Crumb]

In the normal memory area we would count from 0x0000 and upwards... with this method we will define an area of memory for the 680x0 so we'll start from the end of the chunk of memory reserved. The 68k emu will think that the end of the chunk of memory reserved for him is 0x0000 instead of being 0xffff (for example).

We would have something like this:

Real addresses:
0x0000.....(x86 memory)........0x8000...(680x0 memory)...0xffff

The logic address the 68k programs would see will be:
0xffff.....(x86 mem).......0x8000....(68k memory)...0x0000


The data from the x86 memory area would look like this:

(start of memory)...12345678THIS_IS_MY_TEXT...(end of mem)

and after copying it to the 68k area it would always be stored in reverse order and the real aspect would be this:

(start of memory)...TXET_YM_SI_SIHT87654321...(end of mem)

But logically as the 68k addresses will start from the end of the chunk they would look as the x86 memory area

(start of memory)...12345678THIS_IS_MY_TEXT...(end of mem)

If we want to modify the numbers "3456" (4 bytes from the 3rd position) and change them by "ASDF" we would look the variable that stores the real ending address of the 68k memory chunk. Let's say it's 100. Our 4 bytes start in the 3rd byte, so we'll make 100 minus 2(the address)+the size of the data to transfer, the real starting address will be 94, and the real ending address will be 98. We simply copy the bytes byte per byte (using the method I have explained to get the real address) if we want to make a byte per byte copy. If the transfer involves copying a 32bit number, for example 12|34|56|78 in big endian, in the x86 memory it will look like 78|56|34|12, so copying it to the 68k ram will not require swapping the bytes because the memory is already reversed.

Have I explained my idea more clearly?

The thing that should be changed is the 68k emu, to use the addresses in the opposite order. The author of Executor did this previously, but I guess that using memory in the opossite order may require some important changes in UAE's 68k emulator. Once we are inside the emulator there shouldn't exist many problems in changing the addresses... it would be transparent for the programs.

[Crumb]

"Actually wouldn't the 68k see that text as 21ETTX "

well, my example was transfering byte per byte so the result would look as I said. But if the memory transfer was done word by word it would look as you have described. But we have stated that the emulator will use memory in reverse order, so it will read the right values :-)