68k AGA AROS + UAE => winner!

[whoosh777]

here is an idea I have been thinking about for some time,


reading Fabio's comments in the OS4 vs MOS vs AROS thread it
sounds like this hasnt been done,


this idea will probably depress people of several other projects


but it could be a sound way to secure the Amiga's future,


step 1. Port AROS to 68k AGA!

why on earth do that?  :read on,

Let me explain, 2 projects bypass all known issues:

1. AROS: this bypasses accusations of stolen source because its
   open source. Hyperion by using AROS also give it their
   stamp of approval,

2. UAE: The A1 itself uses this, thus it is officially endorsed!

Now the problem with UAE is that it requires ROM ownership,
thus fantastic though it is: I have been told that WinUAE
gives disk speeds of 58Meg/second and it has truecolour etc,

it has the problem that its market cannot grow except through ROM piracy,
 at least not without Amiga co.'s approval,


And the problem with AROS according to Fabios comments is it cannot
run 68k binaries, that was never the projects intention,


So my way around all this is that if AROS is ported to 68k AGA,
that will then furnish an opensource Kickstart ROM for UAE!

I dont know much about UAE but it sounds like it emulates AGA custom chips
and 68k CPU but requires a 68k AGA OS ROM binary to be complete:
enter a very specific almost absurd port of AROS to provide
an opensource freely distributable reimplemented 68k AGA OS3.1 ROM binary,


This way 68k AROS AGA will create open source OS3.1 for all systems,
and the market can then grow, very fast because its for free,
and it will run on all known hardware: Mac, PC, Linux, Unix, A1, Pegasos,

and all existing 68k binaries will run on it,

who needs OS4 if you can do this?

68k AGA code can then be used as virtual machine code,
which means you can have closed source cross platform binaries:
so no need for Amiga DE which also tries this but appears to use
an undocumented binary format and requires a license fee or something,


this means that people can create closed source commercial programs,
IMO for a platform to take off you really need to be able to have
closed source commercial programs,


The Amiga co. can also make money by selling eg OS3.9 to run atop this,

[whoosh777]

by falemagn on 2004/4/4 16:12:33

Quote:



And the problem with AROS according to Fabios comments is it cannot run 68k binaries, that was never the projects intention,




No, wait, that's not what I said, I said that AROS' aim has never been
to run 68k binaries on other CPU's than 68k's, which is quite different...


-----------------------------------


seems I wasnt reading carefully enough,

whats the thinking behind this?

if AROS were to run a 68k binary such as SAS C 6.50 on an Intel machine,
what issue is it that you want to avoid?


Eyetech by using UAE endorse AmigaOS being run on any CPU provided an
official ROM is used,

Hyperion by using AROS code endorse open source reimplementations,

so combining these 2 endorsements we get that
UAE can be used on an open source reimplemented ROM?



-----------------------------------------

@KennyR

AGA? Why AGA? This is hardware dependent and has no future.

-----------------------------------------

really I meant the entire custom chipset, just for compatibility reasons,

interleaved bitmaps are a slow and obsolete concept,

new programs for a new OS shouldnt reference the chipset at all,
probably a good idea to read + write protect the chipset via MMU
for new programs to prevent the chipset being used,

-----------------------------------------------------------------------

@that_punk_guy


>Speculation on my part, since I'm no hardware/HAL guru, but no matter
>how fast you run the emulation,
>it's going to be held back by the architecture - addressing modes, registers, etc
> - that the emulated processor offers. And you can't change them, or you'n
>l break compatibility.

yes, but JIT emulation is pretty fast: Morphos people say theirs is 75% of
native speed,

really its only when you reach a slowdown of 400% that you should start worrying,

if you upgrade your computer to one which is 2 x as fast its quite a disappointment,
when its 8 x as fast then its impressive, IMO 4 x is the cut off point to be
impressed,


also you dont need that many registers, good compilers convert local variables
to registers on a many-to-many basis, you only need maybe 8 or even 4
general purpose registers,

in fact you could get very fast code without any registers due to the
fact that the currently executing functions stack slot will usually
entirely be in the cache, probably in the L1-cache,


the preoccupation with having lots of registers is a hangover from
the days when everyone coded in assembler,


also 3-address code eg "add d0,d1,d2"  (d2 = d0 + d1 ) is also
of dubious merit, Motorola 68k uses 2-address code "add d0,d1" (d1=d1 + d0),

in fact 1-address code "add d0" (accumulator = accumulator + d0) is probably
just as good,

probably even 0-address code "add" (pop pop add push) is also just as fast,

one problem with 3-address code is that you end up with huge instructions
(eg 1 instruction = 32 bits: twice as big as typical 68k instructions),
with 0-address code you could fit 8 instructions in that space,

anyway the point I am making is that 68k's 2-address code with 8 to 16
registers is probably just as good and twice as small as PPC's 3-address code
with 32 registers: most of those 32 registers will be asleep most of the time,

example:

x = y * z + t ;

in 3 address code:

lea y,d2
load 0(d2),d0
lea z,d2
load 0(d2),d1
mul d0,d1,d1
lea t,d2
load 0(d2),d0
add d0,d1,d1
lea x,d2
store d1,0(d2)

(RISC code is like wearing a strait-jacket),

1 address version:

load  y    ; to accumulator
move d0  ; from accumulator
load z   ; to accumulator
mul d0  ; accumulator = accumulator * d0
move d0
load t
add d0
store x

1 address code is actually much more in the spirit of the RISC concept,


Motorola 68k version:

move.l  z,d1
muls.l  y,d1
add.l   t,d1
move.l  d1,x

0 address code version:

push y
push z
mul
push t
add
pop x

:clean + simple,


the 1-address version certainly outdoes the 3-address version on all
counts: smaller + shorter + fewer instructions, fewer overall memory references,


the real gain of having eg 1-address code with eg 4 registers is
you end up with a huge reduction in chip circuitry
=> much smaller => much faster,


>Using AGA emulation in the way you describe is also... well, insane,
> quite frankly. Why toss the Amiga's established RTG system out of the window?

I agree, I'm not stopping you using the RTG system,
I am just thinking of the classic AGA machine as a bootstrap OS,

you can have all the modern stuff you want atop that bootstrap OS,
so eg you can and should have the RTG system,


doing everything via 68k means you eliminate the need for
open source + recompilation,

:it will save centuries of effort and eliminate truckloads of bloat!

open source always becomes very bloated

eg the general trend is for source code that exceeds 9meg compressed,
regardless of what it does, IMO a lot of it is
"tactical" bloat

manufacturing industry is totally closed source,

visit http://ftp.gnu.org/gnu to see what open source really looks like,

now visit http://www.aminet.net to see what closed source looks like,

which do you prefer?

I dont know about you but I only use open source stuff out of necessity,
I much prefer eg SAS C 650 to gcc, but some things can only be done via gcc,

gcc also has some really neat features eg it will convert c to assembler,

---------------------------------------------------

@Karlos

>UAE has to devote considerable CPU resources to emulate AGA at full speed
>(which is tragic considering how slow that definition full
>speed is in modern terms), the *sole* benefit of which is running
>various aga based programs.

but the AGA emulation will only happen if you make AGA calls,
so if you run a modern 68k program that makes no use of the custom chips
then that overhead vanishes,

>All serious amiga software of the last decade or so years has been RTG friendly.

I am not stopping you having RTG,

I am all for modern ways of doing things,

but whichever way you do it I think you need OS3.1 68k compatibility,
and you also want the market to grow. Probably also the Amiga OS has to
tear itself away from the central company and become a 3rd party OS,

all the really interesting developements have come from the 3rd party,

as far as I can see there is no disciplic continuity from the original
Amiga OS creators to Hyperion and they have delivered *nothing*,

ie I think they have no mandate


>Casting that aside, you have this notion of UAE as an "OS", running
>unhosted on your PC that gives transparent 680x0 emulation.
>
>I'm afraid it's already been done. Amithlon was pretty much just that.
>
>I could be wrong, but it still needs OS ROMs to work.

but Amithlon has been derailed by legal issues, also doesnt it need a
ROM to function?

I'm not against AROS reimplemented ROM to use with Amithlon,
same idea,
someone told me Amithlon itself makes use of UAE,

it would also be sensible to try and bring Amithlon to other CPUs such as PPC,


>A replacememnt ROM for Amithlon (and a general update of the whole thing
>wouldnt hurt) based on open source code would pretty much do the job
> you are asking, AGA emulation aside.

I am equally happy with this pathway, I dont know what is the issue
thats stopping Amithlon

>As for how useful it would prove to be, I can't say.

an emulator + a reimplemented ROM may be the only way for the
platform to continue,

IMO the only sensible path for OS4 would be to
use a 68k emulator + OS3.1 ROM binary for backwards compatibility,

you should be able to directly boot OS3.1 on an A1
after about 1 year since the OS4 project begun,

if reimplementing OS3.1 native is nowhere near complete after 1 year,
the project should be shelved and an emulated version worked on,

once a directly booting OS3.1 is available and for sale then
they can work on reimplementing it properly,

but you need to have some product out there and on the shelves,
and on peoples desks,


OS4 shouldnt even be thought about till OS3.1 is complete and
 for sale: either emulated or "ported",


people complain about H & P but at least they delivered OS3.9
which I use every day,


Hyperion havent delivered anything at all,

they know how to grab the OS contract and never ever let go
but not how to deliver the product, not even a bad product,

--------------------------

@bloodline

From what I can see the biggest issue here is bootsrapping the Amiga
before the OS comes into play... if any Demos coders out there want to
have some fun again.. they could do worse than get AROS booting on the Amiga...

--------------------------

if they can get AROS directly booting from an A1 that will be a major
achievement,

will they also need to port gcc to that specific setup?

I would still like the ability to run my 68k programs,

maybe if they can port UAE to run above that version of AROS,

I dont know what the issues are in porting UAE,

[whoosh777]

-------------------------------------------------------

@bloodline

>Booting an A1 with AROS is not that hard, since the A1 has it's own firmware
>(The UBoot BIOS) to bootstrap the hardware... bootstraping a real Amiga
>is much harder since AROS would have to do that itself.. the real
>Amiga's OS and firmware are one and the same.

to what extent is AROS an API as compared to an OS?

If you want to directly boot an A1 not via Linux,
how is this done?:

lets say you buy an A1,
you switch it on,

do you have to create a CD on another machine which you
then boot the A1 with?

How much facilities does A1 UBoot provide?

The code you would run on the A1, how is this created?

is there a cross compiler eg gcc or a cross assembler available
for doing this or do you have to create this first?

I suppose you could go through A1's Linux, but that is cheating,
also cheating would be to borrow Hyperions A1-gcc,

how did the Linux people get Linux on the A1?

A similar problem is creating a game that directly boots up on the A1
bypassing the OS and hitting the hardware directly perhaps through the
UBoot,


For the A1000 I believe they cross compiled the OS from Macs,
this is why Lattice C occurs on both platforms, it was originally a Mac
compiler and they used it to cross-compile AmigaOS (I think):

you then inserted a kickstart disk which loads the ROM to RAM,
and then you booted up with a workbench: floppy,

>UAE runs fine on AROS, but some people would like to see it be able to pass
>OS function calls from the Emulation through to the
>Main AROS OS thus integrating it.

if UAE runs on AROS then that is one way around the problem,
just run the 68k binaries on UAE on AROS,

redirecting UAE through AROS sounds quite a tricky problem,

I think this requires a lot of thought just to understand
the problem properly,

you are attempting to transplant one implementation by a totally
different one,

also some 68k programs may hit the h/w directly which the
redirection wouldnt understand,

it may be more trouble than its worth,


the only neat way I can see to integrate AROS with 68k compatibility is
my initial posting,

that way you completely remove the recompile factor:

both for you: just compile a reimplemented ROM once,
and for programmers: just compile a standard 68k binary just once,

same ROM + same programs then run on all platforms,

and all of www.aminet and geekgadgets and all commercial programs
eg SAS C 650 become available,

once OS3.1 is fully and totally reimplemented you can then
move forwards from this point using emulated 68k but in a
carefully thought through retargettable manner,

ie you would drive arbitrary h/w but through 68k as a virtual CPU,

so eg dos.library can be replaced by newdos.library,

Berndt said in some forum that one problem with dos.library is that
a program can do the following:

f()
{
char x[100] ;
BPTR fh ;

sprintf( x , "filename" ) ;
fh = Open( x , MODE_READWRITE ) ;
.........
}

x is a pointer to a string on the stack, however x can get passed to
another task by Open(), namely one of those filesystem tasks you see
when you run Sysinfo,

this causes a problem that it makes it tricky to have "infinite" stacks,

a popular concept is for all stacks to start at top of memory and grow downwards
via the MMU. This means that the stack is not public memory, ie it cannot
be accessed by other tasks,

dos.library needs to be redesigned so that memory supplied by a task
never gets transmitted to another task,

OS tasks should only receive memory allocated by the OS,
user tasks should be forbidden from allocating OS data structures,
:forbidden by careful API design which makes it impossible,


with exec its quite ok for a program to allocate a struct Semaphore
in fact thats the only way to do it: exec does *not* allocate struct Semaphores
for you,

the user even has to supply the name string which isnt copied by the OS
(see comment in second code fragment on p511 of RKM Libraries 3rd edition),

and these are OS data structures, intuitions API wisely prevents the user
allocating struct Window's,

now if the program does AllocVec( sizeof(struct Semaphore),MEMF_PUBLIC | MEMF_CLEAR);
thats fine,

really it should be the other way round: the only way to create an
OS struct Semaphore should be via some API call eg

struct Semaphore *OpenSemaphore( char *name ) ;

with the OS copying "name" to a properly allocated string and not trusting
the user supplied string
exec's AddSemaphore() shouldnt exist, or at least it should be an internal
private exec call,


these are design subtleties but IMO all the amiga libraries should be
gone through with this subtlety fixed,

OS3.1 has to be reimplemented AS-IS as specified in the RKMs because of
the continuity factor: programmers can then recompile all their programs
to AROS unchanged. via the 68k AGA AROS idea even assembler routines
can remain unchanged in fact recompiling is unecessary just reuse the
existing binary!

However once OS3.1 is reimplemented new improved versions of all the
libraries should be done to run in parallel to the original versions,

another problem to fix with newdos.library is to remove the restriction
on filename length, just replace the inbuilt array by a pointer,
similarly arbitrary length shell command lines should be done,

----------------------------------------

@IonDeluxe

UAE still needs kickstart, and I have not seen anyone talk about an open source
re-implementation of that, or I am blind.
I cant be opensourced until you getourd the kick rom.

-------------------------------------------

there is a blurred line between kickstart and AmigaOS,

apart from the bootstrapping I think most of the kickstart ROM
is just AmigaOS libraries,

if you have reimplemented AmigaOS you may be able to bootstrap
from this:

create by hand the initial minimal interlinked OS datastructures,

so they are self consistent and meaningful,
including execs jump vectors,

create an initial tasks data structures as if it were about
to execute its first instruction,
correctly linked into struct ExecBase,

all interrupt handlers in place,

:kind of AmigaOS in suspended animation,

you need to have total mastery and understanding of your reimplementation to do this,

enable interrupts and now jump
to the first instruction of that task: the breath of life,

that tasks program could be to open dos.library and intuition.library

(DOSBase = OpenLibrary( "dos.library", 0 ) ; etc in machine code)

and then using dos.library it would execute s:startup-sequence,
dos has an API call for executing script files:
SystemTagList( d1 = "s:startup-sequence" , d2 = empty taglist ) ;


dos.library needs to be up and running before you can even think
about s:startup-sequence,


I'm just second guessing here and there's probably many different
ways to do it, bootstrapping is a tricky nightmare!

[whoosh777]

After making the above posting I realised some further things,

1. I think dos.library also needs to be set up by hand in the
bootstrapping because OpenLibrary( ) may require dos.library opened
thus we cannot use it to open dos.library, self-reference,


this is what struct DosLibrary looks like, from dos/dosextens.h:

struct DosLibrary {
  struct Library dl_lib;
  struct RootNode *dl_Root;
  APTR    dl_GV;          
  LONG    dl_A2;          
  LONG    dl_A5;
  LONG    dl_A6;
 struct ErrorString *dl_Errors;        
 struct timerequest *dl_TimeReq;      
 struct Library     *dl_UtilityBase;  
 struct Library     *dl_IntuitionBase;
 } ;

so you would do:  

DOSBase = AllocVec( sizeof( struct DosLibrary ) , MEMF_PUBLIC | MEMF_CLEAR ) ;

and then set up all the above fields, so it looks like you may
need to also set up utility.library, intuition.library, timer.device,
by hand,

I dont see why you need intuition.library, nothing to do with files
except filerequesters, not sure you even need timer.device initially,
dos.library's Delay() probably uses timer.device, but for the bootstrapping
it may not be necessary,

so probably the bootstrap opening of dos.library
doesnt require intuition or timer (save a lot of work!).
Once the initial dos.library is open,
OpenLibrary() could be used to open intuition.library and OpenDevice() to
open timer,

you also need to set up the jump vectors by hand, possibly 200 functions:
write these functions in position independent code in contiguous memory slots after
the above data structure, then you can load a ready made binary in
one disk read (not using dos.library!),

add the offset of DOSBase to all pointers including the jump vectors,

if you are allowed to use an MMU then the bootstrapping could be reduced
to copying a large ready made binary from disk (without using dos.library),
this binary could even include a ready to start task,

you have to create that binary, but I have already begun this here online,
so you just continue.

One way is to create it in C, compile this to assembler,
via "gcc -S xyz.c -o xyz.s", then customise xyz.s by hand into position
independent assembler. Compile then xyz.s to xyz.o and link into an actual
program prog, prog then can copy the binary subset of xyz.o to contiguous
disk sectors,


2. The issue of 64 bit code, this can be done by extending the
68k Virtual CPU instruction set by inventing our own 64 bit instructions!

as its virtual we can design it any way we wish!

also we can probably do a better job than Motorola, (not difficult!),

I have my Motorola m68k series handbook here, and if the first 4 binary
digits of an instruction are 1010 this is unassigned op code!

So my idea is to invent new 64 bit instructions, not exceeding 16 bits width,
with some new 64 bit virtual registers, lets anticipate the future and make
the registers perhaps 256 bits wide but where we currently only use the
lower 64 bits?

complete with new stack pointer and program counter,

all new instructions would begin with the binary digits 1010,

we also would need to reserve a subset for future expansion,
16 bits is a lot of bits, so reserve 10101 for future use,

our instructions could all begin 10100...........

and they would be designed to be emulator friendly so that UAE and
amithlon can be easily extended. gcc would also need to be customised,

we could even email Berndt before finalising the design,

in case you are interested this is how Motorola allocates the first 4 digits
for 68k assembler, (if I have understood them correctly)

0000 = bit manipulation/movep/immediate,
0001 = move byte
0010 = move long
0011 = move word
(ie 00 = move, next 2 digits = size)
0100 = misc
0101 = addq,subq,scc,dbcc,trapcc
0110 = bcc/bsr/bra
0111 = moveq
1000 = or/div/sbcd
1001 = sub/subx
1010 = unassigned: I'm having that opcode!
1011 = cmp/eor
1100 = and/mul/abcd/exg
1101 = add/addx
1110 = shift/rotate/bit field
1111 = fpu instructions/coprocessor interface/M68040 & CPU32 extensions,

there, 68k summarised in 16 lines!

tempting to write a disassembler/assembler just for the
hell of it!

3. Regarding "improving" OS3.1, improvements could actually be
layered above OS3.1, so eg I mentioned Semaphores,
the improved Semaphores could be implemented via the OS3.1 ones:
remove some of the API calls, introduce others,

such layering will greatly reduce the work required,
alternatively just customise the reimplemented OS3.1 source,


I wonder why Intel CPUs got reimplemented by other companies but noone reimplemented the 68k CPUs?

[whoosh777]

by bloodline on 2004/4/7 9:54:16


--------------------------------------
my questions were:

Quote:



to what extent is AROS an API as compared to an OS?

If you want to directly boot an A1 not via Linux,
how is this done?:

lets say you buy an A1,
you switch it on,

do you have to create a CD on another machine which you
then boot the A1 with?

How much facilities does A1 UBoot provide?

The code you would run on the A1, how is this created?

-----------------------------------------------------------

your answer to this is very interesting, it explains several things
I was wondering about,

---------------------------------------------------------

@bloodline:

>AROS is an OS. It currently is able to boot x86 machines and
>Openfirmware PPC Machines.

>If you were to Flash the A1 BIOS with an Openfirmware rom (written for the Terron),
> then AROS could boot it.

so you appear to be saying it can already be done!

and you also seem to be saying that the only dependencies are that its
 Openfirmware, ie the fact its an A1 is irrelevant,

Has this actually been tried out?

What is involved in this flashing of the A1 BIOS?:

lets say someone orders an A1, how do they get the BIOS flashed?

will this clash with running OS4? : what flash does that require, UBoot?

can you switch back and forth between Openfirmware and UBoot?

Have I understood you correctly: you buy an A1, flash the BIOS, download AROS,
boot AROS?

And now can UAE be run just like that on this AROS?

I may go down this path then,

sorry if some of these questions sound ignorant, but I only know in depth
about 68k Amiga,

>I would expect UBoot provides similar features to Openfirmware,
>all it takes is for someone to adapt the AROS Boot code.

are you referring to booting AROS from UBoot??

So are UBoot and Openfirmware the only contenders or are there others?

>A System's firmware initilises the hardware, and brings it to a known state.
>It then Looks for an operating system Loader on the available storage media).
>Once a Loader is found it is executed. The AROS Loader will then load the
>AROS "ROM" code into the memory,
>THat memory is then protected against writing (Since it must be treated as a ROM).

this answers several questions,

now can the MMU be used instead of ROM flashing? ie can UBoot eg remap the
ROM address space to RAM and then copy Openfirmware there and then
metamorphose into Openfirmware or is it more complicated?

>The Loader then preserves all the hardware info from the BIOS into a "safe"
>location... The loader then jumps to the AROS ROM code.
>AROS then takes control of the machine. AROS boots.

does the firmware tell you where all the system memory is located?


are any memory allocation facilities provided or you have to construct these
yourself?

any API provided for reading the drives?


>The Booting precedure is available for view in the AROS source code,
>and If you have any questions you can visit www.aros-exec.org where the
>devs can often be found lurking.

I have to look into this, I feel scared to even look though,
there is something daunting about this, I am afraid to click the link even,
I will click that link, just give me some time!


if I can get an A1 to directly boot AROS and then run UAE above this,
then I think I will go down this path and find out what AROS are doing,


IMO AROS are 10 x as competent as Hyperion,


my interest in this is my own projects that I could run in the AROS
environment so eg I very strictly only use the OS3.0 API and cybergraphics.library,


my interests tend to be nongraphical so eg exec.library interests me
much more than graphics + intuition etc.
Exec really is a masterpiece,

[whoosh777]

by that_punk_guy on 2004/4/7 10:12:07
----------------------------------------------
Quote:


whoosh777 wrote:
The issue of 64 bit code, this can be done by extending the
68k Virtual CPU instruction set by inventing our own 64 bit instructions!

-----------------------------------------------


>And at that point your code no longer runs natively even on the
>lowest common denominator machine: the 68k Amiga.

the 68k architecture anticipates this though:

if you tried executing eg 1010000000000000

which was say at memory location $123400

you would get a "Line 1010 Emulator" exception specifically for
this situation,

I havent done this myself but what I think happens is the
CPU jumps to the trap vector for this exception stored at address $028,
the CPU is in Supervisor mode,

the supervisor stack is in a7 which points indirectly to
the instruction thus:

movea.l 2(a7),a0  ; will move $123400 to a0 (I think),

movea.w (a0),a1 ; will move 1010000000000000 into a1,

which you can now emulate via a subroutine,
my_emulator( a0 = instruction address , a1 = first 16 bits of instruction )

if the extended instructions are thoughtfully designed this emulation
could be ultra fast eg a few machine code instructions,

ie you can patch the 68k CPU to understand the extended instruction set,

[whoosh777]

@bloodline

>Note that the x86 instruction set is more RISC like than the 68k,

how many registers?

0 , 1 , 2 or 3 address code? (max no. of CPU registers per instruction)

can you give some simple examples of x86 assembler?

eg how would you do x = y * z + t   where x,y,z,t are all in memory


how does it do floating point maths?

[whoosh777]

>if you tried executing eg 1010000000000000

>which was say at memory location $123400

>you would get a "Line 1010 Emulator" exception specifically for
>this situation,

>I havent done this myself but what I think happens is the
>CPU jumps to the trap vector for this exception stored at address $028,
>the CPU is in Supervisor mode,

if you want to see the default trap handler for the above exception
in action on your system,
download this binary: http://www.whoosh777.pwp.blueyonder.co.uk/crash1010

it is the program:

THE ORIGINAL VERSION OF THIS WAS WRONG AND DIDNT CRASH CORRECTLY!
SO I HAVE EDITTED THIS POSTING WITH A DEBUGGED VERSION THAT CRASHES CORRECTLY!


unsigned int x ;

void (*y)(void);

int main( int argc , char **argv )
{
x = 0xa0000000 ;
y = (void (*)(void))&x ;

y() ;
return( 0 ) ;
}

I got a crash requester:

crash1010
Program failed (error #8000000A).
Wait for disk activity to finish.

Suspend                    Reboot

exec/alerts.h says that 8000000A is "Line 1010 Emulator error":

#define ACPU_Trace      0x80000009      /* Trace error */
#define ACPU_LineA      0x8000000A      /* Line 1010 Emulator error */
#define ACPU_LineF      0x8000000B      /* Line 1111 Emulator error */
#define ACPU_Format     0x8000000E      /* Stack frame format error */


"Line 1111" is the exception you get if you run a FPU instruction without an
FPU present,

:in theory someone could write an FPU emulator for 68k CPUs lacking FPUs,
(all FPU instructions begin with the binary digits 1111),
that way you could run FPU binaries on non FPU machines,

[whoosh777]

this is embarrassing, but several hours after uploading
crash1010 I was reading a comic about a guy flying an
aeroplane into the future when I suddenly realised
the bug in crash1010, thats why it wasnt crashing correctly!

I've fixed the bug and editted that post with the correct
version that causes the 1010 line emulator trap handler
crash requester,

it now crashes correctly with no. #8000000A,

and I blamed AmigaOS!

anyway I can laugh now,

BTW how do you get the smileys into postings,
I cannot see how to do it, I tried clicking on them
but it doesnt seem to have any effect?

[whoosh777]

@bloodline

>Yes, the fact that it's an A1 is irrelevant. The hardware is a *standard* PPC
>machine.

this thought is running through my mind:

reflash A1 and then run Morphos,
reflash Pegasos and then run OS4,
reflash either and run AROS,


>First you would have to get an Openfirmware BIOS image from someone. I don't know
>if these exist, if they do, then One of the other users of the MAI chipset might
>have one. Check out the Terron.

I assume such BIOS images are "public domain",

I think I have to buy the machine first, I like doing things in the
correct sequence,

>I assume the A1 BIOS can be flashed by software... most BIOS's can be.

can it also be backed up?

would it just be a matter of getting the MMU to write enable the BIOS
and then copy the bitmap?


>OS4 needs UBoot to boot, for the same reason AROS needs Openfirmware.
>THat's what they have been written to use. I don't think it's healthy to keep
>reflashing the BIOS. If one wants to use an Openfirmware PPC machine I
>would suggest they get an old Mac or o Pegasos2.
 
ok, was there any thinking behind their decision to use UBoot?

maybe someone with a Pegasos2 could make their Openfirmware BIOS image available,
ditto A1 UBoot,

> On the PC one can use the MMU to load a BIOS image into memory and then use that
>instead of the ROM BIOS... I assume the same is true of the PPC machines.
 
sounds a much better approach,

> The solution to this problem is to get someone with UBoot experience to adapt
>AROS to use UBoot instead of Openfirmware, That's the simplest solution all round.

>The Firmware tells you how much memory is present
>(Thoguh it's good practice to check while the OS is booting).

>The Memory is always located in it's address space... your question doesn't make
>much sense.

I was thinking in terms of the classic machine where the memory may be
in several noncontiguous segments,

it sounds like you are saying its all remapped into 1 contiguous slot,


>Maybe you mean other memory like PCI space and stuff,
>yes that sort of information is usually gathered by the BIOS,
>and AROS uses that information.


>AROS provides the Memory allocating functions. The Firmware does not need to know
>about stuff like that.

ok, not a major problem,

>Most BIOS firmware does provide a simple API for accessing physical
>sotrage media... how else are you going to load the OS

I was wondering about this,

eg if you have some arbitrary storage device eg USB or SCSI or IDE,
I was wondering how a low level initial API deals with arbitrary h/w,
but maybe the storage device sorts itself out,


>If you want to work on the PPC version of AROS why not help the PPC guys get it
>running on UBoot?

quite possibly, maybe a good approach would be the more general problem of
layering Openfirmware above Uboot,

if Uboot and Openfirmware are both quite simple then this layering may not
be a big deal,

and then layer the reverse way round,

what I may do is buy an A1, and then fool around with the UBoot to try
and understand it and then look into what the AROS people are doing,


>I think Hyperion are perfectly competant, it's hard work writing an OS from Scratch.

I challenged one of them to tell us in detail what they are doing:
on an hour by hour basis, or even on a day by day basis,
which OS library or subsystem, which API calls, are they debugging or
writing new stuff, is the delay because of quantity of stuff or
difficulty of stuff,

is it graphics.library or dos.library or what?

the huge time they are taking must be occupied doing something,
exactly what is that which is so time-consuming,

I realize that coding is very time consuming and an interesting program
feature could take 1 week to achieve,

I got no reply,

for all I know they are lying in hammocks sipping amicola and reading
star-trek-fanzines,


basically I asked them for a captains-log, and got silence,


I emailed Hans-Joerg requesting their 68k hosted cross compiler,
I got no reply, not even "no I cannot send you this because...",


the whole point of a 68k hosted cross compiler is to run it on a
68k machine,


Their website tells you next to nothing,


they have had a whole suite of cross compilers available since last year,
and they still havent released it, they promised on their website on
Christmas day to deliver this.
For Christmas 2002 we were promised OS4 under christmas trees and
on Christmas 2003 all we got was a promise under a christmas tree,

:they cannot release stuff thats already been done, time is of the essence,

you see I think now that the OS4 shown at Pianeta was merely a hacked
UAE, OS4 maybe doesnt exist,

KMOS are behaving exactly like Hyperion, no announces, no presence,
no nothing, they sound like a stooge,


>You project should run fine in AROS, if you have a PC there, then you could
>compile your Apps for AROS right now and use them on your PC with AROS

I only have 68k machines, 2 68000 A500s and a 68030 A1200,
I will try and get some stuff onto AROS though this will probably wait till I am
on PPC or PC, I have lots of useful utilities that I have written to manage
my own system,

eg I wrote a recursive date sorter, feed it a list of directories
eg some partitions and it will recursively sort the entirety by date,

it will cope no probs with an entire CD, (you need enough ram for the
list to fit: 1/2 Gig full partition on my 14 meg 030 was no problem)

it takes n log n time so there is no noticeable slowdown,
it just munches its way through whatever you feed it,

it can cope with up to 2^32 entries,

not a big deal but very fast + useful, took 1 or 2 days to write + debug,

:I use it to find out what I was last up to on a partition if I havent
used it for a long time,

I will upload the 68k version to my site later tonight:

http://www.whoosh777.pwp.blueyonder.co.uk/datesorter.lha

(not there yet as I type this),

example usage:

dates -r ram: -n c: -r -p #?.c df0: -n df1:

        => recursively scan ram:, then non recursively scan c:,
         then recursively scan df0: filtering in pattern #?.c,
          then non-recursively scan filtering pattern #?.c df1:,

merged sorted list is output,

:you can filter in any pattern,

for usage info:

dates ?

or

dates

>Exec is a masterpeice! And getting to look at the Exec sources in AROS is
>really nice

it could help me understand the original exec,

[whoosh777]

------------------------------------------

@bloodline

Ok, the UAE idea, is just that. Run a 68k version AROS on UAE, and run UAE on AROS.

All 68k programs will run in UAE, and they will make OS calls to the 68k version
 of AROS Running in UAE... That 68k version of AROS will be specially designed to
allow it to call AROS functions through UAE. So whe the 68k program calls the 68k
AROS in UAE C
o open a window... the 68k version of AROS calls the x86 version of AROS and that
Opens a window.

when the user clicks on a window that is owned by the 68k version of AROS running
in UAE, the event gets passed through to the 68k verison of AROS which passes to
the 68k program.

If the 68k program tried to hit the hardware, it will have no problems since the
Hardware is emulated in UAE.

------------------------------------------

I am gradually starting to understand the problem,
some ideas on this:

break UAE into 2 programs: UAE_chipset_emulator and UAE_68k_emulator,

implement UAE_chipset_emulator via AROS API calls,

run this as a background prog from AROS: it will read + write protect
the classic chipset address range: any read or write accesses will be
redirected to AROS API calls so eg:

a word write of #$c000 to dff09a will be implemented via
AROS Enable() but with SysBase->IDNestCnt unchanged,


No ROM will be used, classic 68k programs will be directly fed to UAE_68k_emulator
which will directly access the data structures of AROS,

x86 AROS may need to be big endian,

problem: (there may be other problems too),

if a 68k prog accesses a jump vector  eg  jsr -444(a6) for OpenDevice,
the jump vector may be PPC native so you dont want the instruction
emulated:

a huge hack around this is to put PPC native code in the upper half of memory,
ie addresses where bit 31 is 1, and 68k code in the other half,

when the emulator is active read-protect the upper half of memory,
when inactive execute-protect the lower half,

this way when the emulator attempts to read the PPC instruction from
the upper half, you get an exception which toggles
from emulator to PPC CPU,

likewise if the PPC tries to execute a 68k instruction from the lower half,
you get an exception toggling from PPC to emulator,

its just an idea and I havent thought it through too deeply,

but maybe you can fine tune it into real architecture,

[whoosh777]

----------------------------------------------------------------

@Karlos

You do realise that trap based emulation on a real 680x0 is very slow?
Hardly suitable for introducing support for new instruction opcodes to
 a real 680x0 CPU, especially if they were used heavily.

----------------------------------------------------------------

one way out is:

use traps as I suggested, here real 68k instructions are at full speed,
but as you point out the extended instructions will be emulated slowly,

SR + PC have to be backed up by the h/w (and possibly other stuff)= 2 move's,
2 moves to get address + instruction, jsr + rts to the emulator code,

bitfield extractions + switch statements, soon be exceeding 20 instructions,

so,

simplified JIT emulation could speed this up, replace the offending instruction by
a direct bsr to its emulation, the extended instructions would need to be
 designed to be the right size so a bsr will fit, could be done by always following
it with 2 no-op NOP's, (a general bsr requires 6 bytes),

:this way second time round the only overhead is jsr + rts,

self modifying code,



BTW regarding neat 68k instructions, I think movem of 68000 is very
effective eg:

movem.l d0/d1/d2/d3/d4/d5/d6/d7/a0/a1/a2/a3/a4/a5/a6,-(a7)

:a 4 byte instruction to backup 15 registers,

normally would require 15 instructions:

move.l a6,-(a7)
move.l a5,-(a7)
....
move.l d0,-(a7)

(hope I got the order correct),

----------------------------------------
@Hammer

AMD64(X86-64) exposes 16 GPRs 64bit registers, while Pentium IV**
(with hyper-treading) has 8 + 8 GPRs configuration.

-----------------------------------------

16 sounds a good decision,
what about 486 and earlier CPUs?


(the speed advantage of x86 makes me believe that something about
their architecture must be very good, I am curious to know what that is),



@BigBenAussie,

if you have AROS on Linux, why not just use the Linux apps directly on Linux!


for office use why not buy Windows and use MS Apps,
if you have an office you can probably afford this
purchase,


what would be interesting would be Linux-in-a-window to run on any Amiga,

[whoosh777]

@bloodline

who is Crumb?

>If you find a PC in the trash/skip/bin then dig it out and run AROS on it,
>I have several junk machines found that run AROS fine.

I am trying to decide which path to take, PC or A1?

if I buy an A1 I think I can sell it back to Eyetech,
this reduces the risk of making this purchase,

re: reflashing ROMs, could you also run Mac's OS on Pegasos + A1
as well as Morphos + OS4 + AROS on Macs?


Some AROS questions:

1. what compiler(s) are used for recompiling AROS programs?
2. are commercial AROS programs allowed, eg could they sell an
AROS version of IBrowse?

because if AROS is free programs only I see this as a problem,

I am happy to contribute a lot of work for free and I have done for 68k,
but I would also like to sell some programs,

ambitious free programming work is a very good way to learn,
but you can only do it for so long,

if a developer spends 8 months on an OS3.1 program,
then they will be thinking:

shall I give it for free to AROS
or shall I sell it to Morphos + OS4 + 68k + Amithlon people,

now if they can sell it to AROS people they are more likely
to choose the AROS option,

one way out is to only do a 68k version here they can sell it
anywhere they like which is probably what will happen,

some programs will be done for free and some will be very high quality,
but you wont have row upon row of fantastic stuff, just the occasional gem,

the project would certainly succeed but in the spirit of
gnu,


it will become like http://ftp.gnu.org/gnu where 5% is fantastic eg gcc,
5% is self referential eg sed + awk + automake
(you need this because you need this!) and the rest requires a lot
of work to even determine what it is!

ie row upon row of "what on earth is this bloated archive"?

rpm is a red-hat self referential program, current rpm is some 9 meg compressed,
do I want it? no, so why do I use it? because there is lots of interesting stuff
only available in this format. If everything on the internet is in Betelgeusian
then I have to learn that,


I dont know whether Linux allows commercial programs,


put another way if AROS is free things only then there is a danger of
becoming a charity to impoverished Amiga users (such as me )


but if commercial stuff is allowed then the future is bright,


the government used to give free glasses here, (no longer though)
but they were small lensed plastic framed Buddy Holly ones,
they also provided £15 gold rimmed circular John Lennon glasses,

I like your NHS glasses!

are you poor? or just mean?

commercial glasses OTOH are super duper scratch proof + cool looking with nice shaped lenses, well designed
nose-pieces and you have a big choice also they fit better on your face,

you get free education also but apart from some exceptional schools you may
have to share your class with some thugs, but pay (through your nose) and you
get conscientious teachers + fancy equipment and all sorts of extra opportunities,

you want your sprog to learn the piano?

we'll get sproggo to grade 9 on a Steinway with this top tutor, just £40 per lesson,

(I think its called a Steinway and I think its grade 9 but I could be wrong)

-------------------------------------------------------------------------

@karlos

>A trap based emulation which can replace each "emulated" instruction with a jump
>to handling code the first time it is encountered is probably the way to go.
>I think that's how stuff like oxypatcher/cyberpatcher work anyway.


I think the only way to get faster will be via full blown JIT which
is going to be months and months of work, (68k JIT emulation of 68k),

with such a JIT something like move.l d0,d1 will translate as is,
its the position dependent instructions that will be the problem,
pc-relative instructions will also be a problem because the relative
distance can change,


>As for movem, you'd want to check the CPU before making any performance
>assumptions. On the 68040, for instance, it often takes longer than
>multiple move.l instructions (although I'm not totally sure if the same is true
>for 68060).

I have found that the safest way to write assembler is often
just to use simple minded instructions:

the clever instructions often run slower,

68k actually has some instructions which save neither space nor time!

just use an, dn, xyz(an), -(an), (an)+,
and your code will be pretty good, as well as straightforward to
port to a different CPU,

:it will also be much easier to read + debug,


In fact this applies to C as well, if you write a program in a simple
to understand way its often faster than if you try to make it fast,



2 things that assembly language programmers often forget:

1. instructions need to be loaded from ram:

so eg "move.l d0,d1" doesnt reference ram, but the instruction
itself 00 10 001 000 000 000 has to be loaded from ram:,

2. caches:

loop instructions and the stack are almost certainly in a cache so
are read much faster than you think,

[whoosh777]

@bloodline,

from your reply I think I will go down the AROS path,

my line of action being:

1. decide on machine eg A1 or PC?
2. buy machine,
3. familiarise myself with machine,
   if its A1 familiarise myself with UBoot,
4. look into what AROS are doing:
either to contribute directly
or to write or port things to AROS,

so step 2 could be in 3 weeks and step 4 in 7 weeks time,


probably I will always be on the outermost periphery of AROS
 and all other projects as I prefer to be standalone,


Getting AROS to boot directly on an A1 sounds a very high priority
project, so if it hasnt been completed I may join that project,
it also sounds very interesting,


I understand AROS already runs above Linux on A1 so AROS is there
already but not the way many people want,


I am sure I can contribute things to AROS though it may be
several months before I can contribute something substantial,


ambitious projects are slow moving, this is why I am reacting slowly,


I can see that AROS only projects will help tip the balance towards AROS,
"portability" is a virtue but "porting" is strategy,


>>who is Crumb?

>An A.orger who wants inline 68k emulation in x86 AROS

if you compile AROS with big endian Intel gcc then you can have
seamless 68k + x86 AROS integration using some variant of my
suggestion,

read + execute exceptions would toggle between emulated and nonemulated
instructions,

Amithlon has a big endian Intel gcc on www.aminet.net,


If the bytes of RAM are  $12 $34 $56 $78 ...........

a big endian CPU sees this the way I have written it and

sees the first int of memory as $12345678

a little endian CPU sees this as .......... $78 $56 $34 $12

and reads the first int (address 0) as $78563412 totally different from
what the big endian CPU sees,

thus the 68k emulator is in danger of clashing with the x86 CPU,

eg addresses will be mangled,

resolve all this via a big endian Intel gcc compile of AROS:

68k and x86 can then access identical OS data structures,

>I'm not sure Eyetech would want to buy your A1 back...
>not with out a massive loss (more than the Price of a PC!).

they have a buy back policy with a depreciation formula,
not sure where I read this, but you could calculate how much
you lose,

I would only sell back the core machine, I would keep the peripherals,
the peripherals anyway wouldnt be bought from Eyetech


Would there be any point in creating your own AROS PPC platform?


:you could then open up the marketting policy,


>I suggest you talk to people and look around for the machine that
>best suits your needs for the lowest cost.
>(click the link for BlackTroll for great prices on AROS PCs)

>Yes you can run MacOS on both the A1 and the Pegasos,
>by using a special program called "Mac-on-Linux",
>but then you need to run Linux too.

I was thinking of directly doing it by reflashing the ROM,
but Mac being Mac probably have some proprietory obstacle to prevent this,

>MOS and OS4 don't run on the Mac. AROS should though.

>The Default Compiler is gcc.

this is the deciding factor,

which versions?

I hope you have gcc2.95.3-4 even though its not the most current,

is it a specifically AROS gcc or do you reuse generic ones?

Have you got 68k hosted cross compiler gcc's (PPC , Intel) for AROS?

(preferably gcc2.95.3-4),


>One AROS dev works in SAS/C on a real Amiga though.

SAS/C 650 compiles considerably faster (seconds) than gcc (minutes)
and produces slightly better code unoptimised than gcc -O2 optimisation,

gcc has its own strengths,

if I can use either I always use SAS/C, sometimes though
the only way to do something is with gcc,


eg ISTR that a really huge static array such as 1 million entries
(eg automatically generated look up table such as
 int x[]={ 1 , 2 , 3 , ..., 1000000} ;} )
will crash the Amiga linker but I think gcc will be ok,


>But to compile for the x86 you need to use gcc.
>We also have an x86 Assember program, as well as BASIC, False and Python all
>included with AROS.

you realise that gcc is also an assembler, the moment a platform has gcc
it automatically has an assembler:

gcc -c xyz.s -o xyz.o

will assemble xyz.s, gcc uses nonstandard cross-platform assembler syntax though
eg for 68k gcc:

.text
 .even

.globl _function

_function:

 move.l #0,d0 /* this is a gcc assembler comment */

 rts

to compile function()


it doesnt understand xref and xdef, .globl is xdef, xref is implicit,
so it wont assemble traditional 68k progs, they need fixing for gcc


I think it uses c style #define's for its macros, so it wont understand
Metacomco's macros,


on x86 it would also be .text, .even, .globl, /* comments */,
which reduces the learning curve,

to compile eg specific 68040 instructions you would type:

gcc -m68040 -c xyz.s -o xyz.o

(the default is 68000 + no FPU),

gcc -m68881 -m68020 -c xyz.s -o xyz.o

for 68020 + FPU code,

>Of course you can run commercial apps on AROS.
>That fits with my personal computer paradigm:
>
>1. You pay for the harware.
>2. You pay for the drivers.
>3. You pay for the software.
>4. But the OS is free and open source.

this is a deciding factor for me,

so eg commercial AROS IBrowse can be closed source?

(I think they wont do it open source)


>In fact the AROS licence even allows you to sell AROS,
>with certain conditions applying, this is how the MorphOS team
>are able to use the AROS sources (they bug fix the code they use).
>
>I hope to see comercial software appearing for AROS once it gets better established.
>


there is an opportunity immediately available for you here:


iospirit announced they have abandoned OS4 development,
there was a link to this from AmigaWorld.net at the time of the
KMOS takeover,


ask iospirit if they will recompile + sell IBrowse to AROS,


they have nothing to lose by doing this,
they already have an up and running website for selling IBrowse,


IBrowse is currently the flagship commercial program for the Amiga,


this would be a major coup,


tell them that you are working towards directly booting AROS on the A1,


AWEB is also now open source, so recompile that and you also get that,
(possibly it may need some work to compile it on gcc)

[whoosh777]

by Karlos on 2004/4/11 1:05:26

Quote:



>>Amithlon has a big endian Intel gcc on www.aminet.net,




>They have a 680x0 hosted gcc that produces x86 code for amithlon.

>AFAIK, there is no such thing as big endian x86.

not totally sure, I have this installed,

I created ram:xyz.c

extern int x ;

void f()
{
x = 0x12345678 ;
}

and now compiled it:

bin/i686be-amithlon-gcc -O2 -S ram:xyz.c -o ram:xyz.s

this generated x86 assembler:

 .file "xyz.c"
 .version "01.01"
gcc2_compiled.:
.text
 .align 4
.globl f
 .type  f,@function
f:
 bswap %ebp
 pushl %ebp
 bswap %ebp
 movl %esp,%ebp
 movl $2018915346,x
 movl %ebp,%esp
 popl %ebp
 bswap %ebp
 ret
.Lfe1:
 .size  f,.Lfe1-f
 .ident "GCC: (GNU) 2.95.3 20010315 (release/lcs-2002-02-08)"

not sure what its doing, it looks like neither endianess,
anyone understand x86 assembler?

$12345678 is 0001 0010 0011 0100 0101 0110 0111 1000 in binary,

the above code has

$2018915346 which is 0010 0000 0001 1000 1001 0001 0101 0011 0100 110

which looks totally different,

not sure whats going on,

bswap looks like some kind of byte reversal but what is
it reversing?

(BTW it looks like its using some 1-address code
which is a good move IMO)



I was under the impression that it generates big endian code,
I think its also available for other platforms such as PPC,

when I say big endian, what I mean is that
for 2-byte word and 4-byte long accesses it will reverse the
byte order before accessing ram:

say we have:

int *x;

x* = $12345678 ;


on big endian we would get:

byte[ x ] = $12 ;  byte[ x + 1 ] = $34 ; byte[ x+2] = $56 ; byte[ x+3]= $78 ;

(*A*)

on little endian (read carefully!):

byte[ x+3 ] = $12 ; byte[ x+2 ] = $34 ; byte[ x + 1 ] = $56 ; byte[ x ] = $78 ;

ie

byte[ x ] = $78 ; byte[ x + 1 ] = $56 ; byte[ x + 2 ] = $34 ; byte[ x + 3 ] = $12 ;

so to implement big endian on little endian:


x* = byte_reverse( $12345678 ) ; /* some CPUs may have an assembler instruction for this */

which would do

x* = $78563412 ;

ie

byte[ x ] = $12 ; byte[ x+1]=$34 ; byte[ x + 2 ] = $56 ; byte[ x + 3 ] = $78 ;

identical to what big endian would do see (*A*) above,

so as long as all memory accesses are intercepted with a byte reversal
by the compiler then Intel will behave as if it were big endian,


>>resolve all this via a big endian Intel gcc compile of AROS:

>>68k and x86 can then access identical OS data structures,




>Again, I have no idea what you mean by "big endian intel".

rewording will help:

((big-endian-ram)-emulation) gcc for Intel,

usual Intel CPU but a compiler that
intercepts all memory reads + writes by byte reversal:

for reads:

1.read memory
2.byte reverse it
3. use it,

for writes:

1. have data
2. byte reverse it
3. write it

>Thus 680x0 is big endian by definition but its a bit odd if you consider
>register-only byte/word/long operations - the effect is litte endian.
>That is, a byte/word operation always affects the LSB/LSW of the register.
>Do the same thing on a 32-bit memory operand and you find the MSB/MSW is affected:
>

>Imagine you have the value 0x01000001 in a memory address pointed to by (a0)
>
>move.l (a0), d0
>add.b #1, d0 ; least sig byte is affected
>move.l d0, a0
>
>gives 0x01000002
>
>is completely different behaviour to
>
>add.b #1, (a0) ; most sig byte is affected
>
>which gives
>
>0x02000001

I wasnt aware of this subtlety, usually inconsistencies such as this are
a sign of bad design,

with good design everything should be logically harmonious,

what they should have done is that the most significant register byte should
be affected and that eg

move.b   (a0),d0  

would load the number to the most significant byte of register d0,

I think you have located another design flaw of the 68k architecture,

maybe we should reimplement and improve 68k! eg:

fix this problem,
remove all the silly addressing modes,
remove pointless opcodes,
make all registers general purpose: where it currently says
 effective address=mode xxx register xxx
we replace this by
 effective address=mode xx register xxxx
(x = binary digit),
make exception frames store their size,
create huge caches,


the 68030 MMU OTOH is very well designed,
much better than the PPC MMU,


You know that PPC has a CPU flag that allows you to select whether
its big or little endian,


BTW regarding things which look fast but arent:

I was studying CPU registers + stack in supervisor mode
and other system things when I observed
that my A1200 supervisor stack pointer is at the top of chip ram ie
$200000,

so I thought I would speed it up by moving it to fast ram, I did this,
and then timed some graphics + disk intensive stuff and found it
made no difference at all!