If you had the chance to build a new Amiga

[meynaf]

Originally Posted by Gorf

in my secret ones

as mentioned before "my" OS is heavily based on message passing - very fast message passing. Lots of things, that are now done via library calls would be replaced with messages. almost everything system related and everything hardware access related - except you grant a trustworthy app the rights for direct hardware access.

That is done to provide a simpler and more elegant way of multiprocessing and resource management and tracing ... as well as a simpler way of sandboxing.

So the whole system performance relies on the speed messages can be exchanged... that's why it needs a single address space and fast context switching.

This looks like nice theory on the paper.

The crux seems to be how the messages look like.
If they can be put in registers, not the same story as if they have to be stored in memory.

Originally Posted by Gorf

it is bi-endian
and Michal's "Emu68" runs under big-endian AROS for ARM.

My point was, most ARM - like the ones in handheld devices - run little endian.

Originally Posted by Gorf

sure. but doing it in VHDL for an FPGA is not really simpler...

True.

Originally Posted by Gorf

how many registers would your CPU have?

16 general purpose ones, like 68k (and a few control regs as well, obviously). More would kill the encoding. Furthermore, asm experience has shown that when 68k registers aren't enough, only very few are missing.
The stack pointer would be separate, exactly like the program counter.
I also have a special 'base reg' for pointing into variables (typically a4 or a5 in 68k programs), which isn't among the general purpose ones.
That's two extra registers, it seems few but in many cases it solves the register conflicts.
However, it doesn't help vm implementation...

Apparently having many regs to emulate has to be handled by dynamic register allocation, mapping emulated registers to host registers differently for every block.
For me this is only theory, i don't know the algorithms involved.

Sure my cpu would emulate 68k easier than the other way around.

[phx]

Originally Posted by Steril707

The Amiga has tried to go that route and it failed already.
It is a hobby box these days.

And I (and most other people) am cool with that.

In all the time I have been following the Amiga scene people have never been more relaxed about it than now that people gave up that pipe dream of the Amiga needing to challenge Apple and Microsoft.

That's absolutely the best post in this thread! I can only say that I completely agree with Steril707, meynaf and roondar.

Strange, that mostly coders share that same vision. It also means that nobody would write software, if you ever get new hardware. Which is exactly what happened to OS4.x and MorphOS - and I predict there won't be much Vampire software either.

[roondar]

I'd say that this is because I'd guess (some/most?) coders who code for the Amiga now do so because they like working with the old Amiga chipset/OS and like the limitations this poses. This is certainly true for myself at any rate. I like the tinkering within a box with fairly strong limitations on what can and can't be done by simply having the CPU/GPU brute force it.

BTW, I do also see the appeal of a "Spectrum Next" style Amiga. But I'd probably aim such a machine at a lower end than some of today's projects do. Meaning I'd probably stick with a low end CPU (68030 or something on that order) and a fairly modest increase in graphics/sound ability. That said, if I'm 100% honest - I might find such a machine a very cool idea, but I'm not so sure I'd actually end up coding for it...

[Nosferax]

OK, lets play...

Hardware: No need to reinvent the wheel. I'd go with any x64 based AMD/Intel system. No need to go all exotic on hardware since it doesn't matter much in the end, all compatibility with the classic Amiga will be done via software.

A custom case and keyboard option could be available. The Checkmate A500++ could be an option for those with the $$$ to afford it.

Software/OS: Custom Arch based Linux distro with seamless integration of FS-UAE, as in you can double click an Amiga 68k program and it'll launch like any other Linux application like Parallel does on the Mac. The GUI would be a customized GTK3 or Qt based one themed to be familiar to AmigaOS/Morphos users, just like people are replicating Mac OS X with Gnome and Kde.

Programming: IDE would be VS Code/Atom/Electron based with VBCC integration plugins for classic 68k programming and C/C++, Python, JS/Electron for the Linux side of things.

The PRO of this:
Everybody who owns a PC with those hardware spec could try it out. If you're reading this on a computer then you can use this!

It's also easier to fix bugs and correct mistakes in software than in hardware, so easier to support. The OS being Linux is being maintained by thousands of professionals worldwide instead of a couple of geeks in their bedroom or basement so you'll get update almost daily instead of every 3 years or so.

You have instant access to thousands of applications to use and you're free to code your own as the system comes with all the dev tools and libraries needed.

You aren't restricted to soon to be obsolete hardware, since this is a software based solution. Your Neo-Amiga can evolve in time and you can do selected hardwares updates.

The Cons:

You don't get an Amiga Logo on the case unless you put one yourself.

You don't have to buy it from Amigakit or A-Eon at ridiculous prices.

[Gorf]

@ Nosferax

what is he difference to "Rabbit Hole" in Amikit?

This special feature of AmiKit allows you to launch Windows, Mac or Linux applications (depends on your host computer) directly from your emulated Amiga and run them on your Amiga desktop.

ok .. having nice full featured IDE would be nice ... but otherwise, we are already there.

[Nosferax]

Originally Posted by Gorf

@ Nosferax

what is he difference to "Rabbit Hole" in Amikit?




ok .. having nice full featured IDE would be nice ... but otherwise, we are already there.

The difference is that unless you need to run an Amiga program, you aren't running the emulator and are instead using the Linux system directly. The integration of FS-UAE would launch the emulator and the program in either a window or fullscreen. Amigakit makes the emulator the main windows with its limitations.

[Gorf]

Originally Posted by meynaf

This looks like nice theory on the paper.

The crux seems to be how the messages look like.
If they can be put in registers, not the same story as if they have to be stored in memory.

that depends on the class of messages.
the goal is of course "zero copy" and therefore pointers and/or data in registers.
This works fine for immediate calls (synchronous messaging)

But sometimes a asynchron approach is more useful or even necessary (eg if a resource is booked or data flow needs to be serialized). In that case message ports and message queues are used.

in both cases a message likely contains a pointer to some other data in some mutually accessible memory region. To avoid costly address translation a single address space should be used.

My point was, most ARM - like the ones in handheld devices - run little endian.

but you can switch the mode. in newer ones even dynamically.

16 general purpose ones, like 68k (and a few control regs as well, obviously).

So AArch64 offers almost twice the number.
So this would definitively not be a showstopper for implementing a JIT.

More would kill the encoding. Furthermore, asm experience has shown that when 68k registers aren't enough, only very few are missing.

I even had something more 8+8 in mind ... meaning not all 16 registers are general purpose ... that has some advantages in encoding off course
(that's why ARM32 treats only 8 of its 16 registers as GP when in THUMP-mode)

The stack pointer would be separate, exactly like the program counter.
I also have a special 'base reg' for pointing into variables (typically a4 or a5 in 68k programs), which isn't among the general purpose ones.

plus maybe some "real pointer" like mentioned above and some special "spare" registers that can be used as scratchpad and for communication (see messaging) - these registers need no connection to the ALU except for MOVE..

than we would end up with a 8+8+8 configuration...

[Gorf]

Originally Posted by Nosferax

The difference is that unless you need to run an Amiga program, you aren't running the emulator and are instead using the Linux system directly. The integration of FS-UAE would launch the emulator and the program in either a window or fullscreen. Amigakit makes the emulator the main windows with its limitations.

it works a program launcher and (transparent) X-Window manager - so what are the limitations?
What does a Linux window manager or "desktop environment" really offer besides the above?

but sure: you could do it the other way around, like JanusUAE does on AROS.
(or some earlier version of AROS did on Linux before that hack was deprecated ...)

So you basically want a JanusUAE for Linux and a nice Windowmanager (there about 3 billion out there...)

[meynaf]

Originally Posted by Gorf

that depends on the class of messages.
the goal is of course "zero copy" and therefore pointers and/or data in registers.
This works fine for immediate calls (synchronous messaging)

But sometimes a asynchron approach is more useful or even necessary (eg if a resource is booked or data flow needs to be serialized). In that case message ports and message queues are used.

in both cases a message likely contains a pointer to some other data in some mutually accessible memory region. To avoid costly address translation a single address space should be used.

If address translation performance is an issue, there is still the possibility to implement it in HW...

Originally Posted by Gorf

but you can switch the mode. in newer ones even dynamically.

You mean by software ? And Android's gonna allow you to do that in a per-process basis ?

Originally Posted by Gorf

So AArch64 offers almost twice the number.
So this would definitively not be a showstopper for implementing a JIT.

There are other showstoppers in that case.

Originally Posted by Gorf

I even had something more 8+8 in mind ... meaning not all 16 registers are general purpose ... that has some advantages in encoding off course
(that's why ARM32 treats only 8 of its 16 registers as GP when in THUMP-mode)

Heh, how do you think i planned doing it ?
When i said 16, it's actually 8+8. Nothing i could think is better than the 68k D/A way.

Thumb-2 allows using all regs, but accesses to R8-R15 requires bigger instructions.
x86-64 has 8 more regs, but there the access needs a prefix - again larger code.
The 68k's D/A split may be criticized, but it's just because it has been limited too much - the encoding system allows more than what we currently have.
In addition, the address regs can behave differently to data regs - in regard to the ccr and automatic extend. This provides extra features instead of reducing them.
Anyway, this is the way i've chosen.

Originally Posted by Gorf

plus maybe some "real pointer" like mentioned above and some special "spare" registers that can be used as scratchpad and for communication (see messaging) - these registers need no connection to the ALU except for MOVE..

than we would end up with a 8+8+8 configuration...

Yeah, something like that.

[Gorf]

Originally Posted by meynaf

If address translation performance is an issue, there is still the possibility to implement it in HW...

ok... do you have any link or information, how this is done in a hybrid 32/64bit CPU?

You mean by software ? And Android's gonna allow you to do that in a per-process basis ?

Probably not in in Android, since the program is running in a Java or Dalvik VM... or run through the ART compiler..

But why the hell are you thinking of Android anyway??
That would certainly be the worst OS to run your vCPU on..

Linux (or any os with direct hardware access) will allow to switch the endianness of data (ARM instructions look always the same)
But you can also simply boot a big-endian linux ...

There are other showstoppers in that case.

such as?

Heh, how do you think i planned doing it ?
When i said 16, it's actually 8+8. Nothing i could think is better than the 68k D/A way.

Thumb-2 allows using all regs, but accesses to R8-R15 requires bigger instructions.
x86-64 has 8 more regs, but there the access needs a prefix - again larger code.
The 68k's D/A split may be criticized, but it's just because it has been limited too much - the encoding system allows more than what we currently have.
In addition, the address regs can behave differently to data regs - in regard to the ccr and automatic extend. This provides extra features instead of reducing them.
Anyway, this is the way i've chosen.

Sounds good

Yeah, something like that.

[Nosferax]

Originally Posted by Gorf

it works a program launcher and (transparent) X-Window manager - so what are the limitations?
What does a Linux window manager or "desktop environment" really offer besides the above?

but sure: you could do it the other way around, like JanusUAE does on AROS.
(or some earlier version of AROS did on Linux before that hack was deprecated ...)

So you basically want a JanusUAE for Linux and a nice Windowmanager (there about 3 billion out there...)

And you don't want that?

Would you prefer an ugly one that nobody will ever use and support? If your end goal is to create a new unsupported hardware platform and OS from scratch just for your lonely self then have at it. There's already plenty of 8 and 16 bit homebrew computer and OSes projects already.

If instead is to have something to code and run programs for the classic Amiga and a modern non dead-end platform, then my solution is way quicker, cheaper and efficient, and in the world of computers this is what makes a project viable or not.

[meynaf]

Originally Posted by Gorf

ok... do you have any link or information, how this is done in a hybrid 32/64bit CPU?

This isn't rocket science... There is 32-bit address as input, 64-bit address as output (or vice versa). Could be an instruction, or some hw register.

Originally Posted by Gorf

Probably not in in Android, since the program is running in a Java or Dalvik VM... or run through the ART compiler..

But why the hell are you thinking of Android anyway??
That would certainly be the worst OS to run your vCPU on..

Most ARM systems on the market actually run on Android, don't they ?

Originally Posted by Gorf

Linux (or any os with direct hardware access) will allow to switch the endianness of data (ARM instructions look always the same)
But you can also simply boot a big-endian linux ...

On what kind of machine would this run ?

Originally Posted by Gorf

such as?

ARM asm ? Troubles doing graphics/sounds/whatever on host OS ?

[Gorf]

Originally Posted by Nosferax

And you don't want that?

I am actually done with linux as a desktop.
I started to play around with linux since its early days - back then on my A3000 ... first some 68k Debian , later PPC Red Hat.

And from than on I went through all kinds of distributions on PC hardware ...
(also some BSDs)

The result: as a desktop Linux is a bloated, complicated, terrible mess.
only Windows is worse.

I still use Linux as server-OS on a bunch of machines, but switched to macOS as my desktop OS.

Since Linux is still only used by <1% of all desktops, we can assume most people don't want it.

Would you prefer an ugly one that nobody will ever use and support?

There are already tons of WMs and DEs out there - some of them are quite beautiful. But they don't solve the mess Linux is.
Putting lipstick on a pig...

If your end goal is to create a new unsupported hardware platform and OS from scratch just for your lonely self then have at it. There's already plenty of 8 and 16 bit homebrew computer and OSes projects already.

true.
But Amiga is and was 32bit.
And a new project would be 32/64bit.

If instead is to have something to code and run programs for the classic Amiga and a modern non dead-end platform, then my solution is way quicker, cheaper and efficient, and in the world of computers this is what makes a project viable or not.

your solution is already there.
you did not answer what exactly the limitations of "Rabbit Hole" are compared to a native linux DE.

Except the Amikit solution is not limited to Linux, but runs on Windows and macOS as well.

So it is surely the quickest and cheapest solution, since everyone can keep on using the hardware and OS he/she already has.

[Gorf]

Originally Posted by meynaf

This isn't rocket science... There is 32-bit address as input, 64-bit address as output (or vice versa). Could be an instruction, or some hw register.

but where does that information come from?
Task A stores a 32bit address in a register and hands over to task B.
Task B lives it its own 32bit address space - so it runs the instruction "give-me-real-address" on that 32bit-pointer from task A in the register ....

now how would that instruction work?

and how would task B now gain access to the data stored outside its own address space?

Most ARM systems on the market actually run on Android, don't they ?

relevance?

On what kind of machine would this run ?

RaspberryPi...

https://www.patreon.com/posts/are-all-big-21150080

ARM asm ? Troubles doing graphics/sounds/whatever on host OS ?

so how about AROS as host?

[meynaf]

Originally Posted by Gorf

but where does that information come from?

Does it need to come from a particular place ? I'm just guessing.

Originally Posted by Gorf

Task A stores a 32bit address in a register and hands over to task B.
Task B lives it its own 32bit address space - so it runs the instruction "give-me-real-address" on that 32bit-pointer from task A in the register ....

now how would that instruction work?

Task A stores a 32 bit address in a register and hands it over to the OS.
The OS converts it to 64 bit flat (this is single mmu remap), then maps it somewhere in 32 bit space of another task (by normal task switch and some mmu changes).
This, only on a pure 64-bit machine (these are monster machines so they can handle it).

Originally Posted by Gorf

and how would task B now gain access to the data stored outside its own address space?

Directly, because it is now in its own address space.
OR we could decide to have a shared area, permanently mapped in the space of everyone.

Originally Posted by Gorf

relevance?

That may be of relevance if you want your vm run on the most common hardware.

Originally Posted by Gorf

RaspberryPi...

https://www.patreon.com/posts/are-all-big-21150080

The advantage of ARM is its commonness. I don't think RasPi applies here...

Originally Posted by Gorf

so how about AROS as host?

That's ok, as long as no direct hardware access has to be made.

But anyway, on second thought, the advantage of a software VM is that it could in theory work everywhere !
Then we needn't choose a specific host. It has to work on as many hosts as possible (mine already does on AOS 3.x, albeit very very slow).

[Gorf]

Originally Posted by meynaf

Does it need to come from a particular place ? I'm just guessing.



Task A stores a 32 bit address in a register and hands it over to the OS.

BREAK!

that's the kind of indirections I try to avoid.
sure: let the kernel do it ... in the end we just recreating UNIX..

The OS converts it to 64 bit flat (this is single mmu remap), then maps it somewhere in 32 bit space of another task (by normal task switch and some mmu changes).
This, only on a pure 64-bit machine (these are monster machines so they can handle it).

Directly, because it is now in its own address space.
OR we could decide to have a shared area, permanently mapped in the space of everyone.

and same goes for all kind of libraries and message ports and so on ...
this gets ether very complicated for hundreds of tasks, if you want individual rights and fine grained capabilities - or rather restricted ...

not happy with that kind of approach ...

That may be of relevance if you want your vm run on the most common hardware.
The advantage of ARM is its commonness. I don't think RasPi applies here...

i don't get that point ..

That's ok, as long as no direct hardware access has to be made.

But anyway, on second thought, the advantage of a software VM is that it could in theory work everywhere !
Then we needn't choose a specific host. It has to work on as many hosts as possible (mine already does on AOS 3.x, albeit very very slow).

ok sure - a linux or bsd kernel will run everywhere - so does probably SDL for gfx and sound abstraction ... the problem is still the JIT, which is always hardware dependent ...
and that's why I was mentioning Michal's Emu68 ... that is ARM (if we like it or not) and is low-level an fast and runs on very cheap yet capable hardware
and it could probably be adjusted for a different instruction set.

it was just an idea after all ;-) that's what this thread is for, isn't it?

[meynaf]

Originally Posted by Gorf

BREAK!

that's the kind of indirections I try to avoid.
sure: let the kernel do it ... in the end we just recreating UNIX..

Then i'm afraid you will get an OS incompatible with any kind of memory protection.

Originally Posted by Gorf

and same goes for all kind of libraries and message ports and so on ...
this gets ether very complicated for hundreds of tasks, if you want individual rights and fine grained capabilities - or rather restricted ...

not happy with that kind of approach ...

Well, perhaps you have to reconsider the idea of using messages for everything.

Originally Posted by Gorf

i don't get that point ..

You want your VM to run on many machines or you want it to be only for a few geeks ?

Originally Posted by Gorf

ok sure - a linux or bsd kernel will run everywhere - so does probably SDL for gfx and sound abstraction ... the problem is still the JIT, which is always hardware dependent ...
and that's why I was mentioning Michal's Emu68 ... that is ARM (if we like it or not) and is low-level an fast and runs on very cheap yet capable hardware
and it could probably be adjusted for a different instruction set.

No, that wasn't my point.
When i write the vm can work everywhere, of course one version has to be written for every supported platform.

Originally Posted by Gorf

it was just an idea after all ;-) that's what this thread is for, isn't it?

Yep.

[Gorf]

Originally Posted by meynaf

Then i'm afraid you will get an OS incompatible with any kind of memory protection.

nope - that is already sorted out.
watch the video I linked earlier

Well, perhaps you have to reconsider the idea of using messages for everything.

and let's do another monolithic kernel... because otherwise we run in the old microkernel dilemma ... but than we can just use Linux Haiku or maybe Fuchsia

That is exactly the point: a micro- or exokernel will always need fast message passing and that does not play well with isolated address spaces.

I have a very different approach in mind but it needs some support by the hardware it runs on (memory protection unit)

Actually the question only was: targeting 32bit or 64bit?
A hybrid approach seems to bring more problems than solutions ....

You want your VM to run on many machines or you want it to be only for a few geeks ?

I suppose it will only be used by geeks anyways in the beginning.
If it creates some attraction people will start to support more platforms ...
(and it's YOUR VM )

No, that wasn't my point.
When i write the vm can work everywhere, of course one version has to be written for every supported platform.



Yep.

[Samurai_Crow]

Re:Next Gen VM

If we're going to the trouble of making a VM, why not use WebAssembly as the basis for the CPU target? It's already in existence and compiles ahead-of-time rather than via JIT.

As for device drivers, if we're going to reinvent the wheel let's do it right. AmigaDE had a seldom advertised feature that allowed hardware banging to be encapsulated in the drivers but macro substituted when compiling. This will give an advantage over other VMs.

[meynaf]

Originally Posted by Gorf

nope - that is already sorted out.
watch the video I linked earlier

Sorry, no english videos for me - i just can't take it.
But even if you have memory protection, you still have a very nice security hole if every task is allowed to access other tasks memory space - even if it's just for reading.

Originally Posted by Gorf

and let's do another monolithic kernel... because otherwise we run in the old microkernel dilemma ... but than we can just use Linux Haiku or maybe Fuchsia

Well, ok, perhaps it's not a great idea to duplicate what already exists...

Originally Posted by Gorf

That is exactly the point: a micro- or exokernel will always need fast message passing and that does not play well with isolated address spaces.

But does message passing really need to be THAT fast ?

Originally Posted by Gorf

I have a very different approach in mind but it needs some support by the hardware it runs on (memory protection unit)

Concrete example please ?

Originally Posted by Gorf

Actually the question only was: targeting 32bit or 64bit?
A hybrid approach seems to bring more problems than solutions ....

If you choose full 32 bits you escape the problems and you're limited to 4Gb memory.
If you choose full 64 bits you inherit bloat in various ways.
What's your choice ?

Originally Posted by Gorf

I suppose it will only be used by geeks anyways in the beginning.
If it creates some attraction people will start to support more platforms ...
(and it's YOUR VM )

That's right, although i don't think 'people' will support more platforms for me even if they like my vm...

Originally Posted by Samurai_Crow

If we're going to the trouble of making a VM, why not use WebAssembly as the basis for the CPU target? It's already in existence and compiles ahead-of-time rather than via JIT.

For two reasons :
1. Ease to code. Stack based horrors are out of the league.
2. Code density. Same.