Next gen Amiga

[meynaf]

Originally Posted by Gorf

you mentioned instruction fusing... and maybe your instruction set would be a good intermediate representation:

a sophisticated decoder/translator in FPGA would find that both code snippets do the same in the end and can be represented by a single (intermediate) instruction.

The FPGA would take every instruction and identify the group. it can do that in parallel with many instructions.(parallelism)

In the second step it compares every instruction with the one that follows - if it belongs to the right group and such a comparison makes sense. Meanwhile the next group of instructions are passing through step one. (pipelining)

in the third step matching couples of instructions are fused - there can be more than one fusing step. (meanwhile an other group of instructions enters step one und former step one instructions go to comparing in step two....)

Now we would end up with a architecture independent and very short intermediate representation of the code.
Traversing a LUT or a tree each intermediate instruction would be translated in either host-cpu code or send to some special simd-unit in FPGA.

there could be more than one of these decoders/translators allowing for some kind of "speculative translation" of branches.

My ISA isn't an "intermediate representation". It is made to be used on its own. I have a (slow but relative complete) software VM for it. It's even better than 68k to code on.
What do you want, use it as microcode ? It's close to insulting.
And not even valid technically. Registers, addressing modes, flags, nearly everything is different to other cpu, even 68k. You can not convert code directly (else i would have had a jit for it already). In short it's not a set of macros for 68k.

You want to do the "next gen amiga" properly ?
Then first we need a cleaned-up cpu. As even though 68k is currently the best, it has its shortcomings, of which only a part can be fixed without going the incompatible way.

[Gorf]

Originally Posted by meynaf

My ISA isn't an "intermediate representation". It is made to be used on its own. I have a (slow but relative complete) software VM for it. It's even better than 68k to code on.
What do you want, use it as microcode ? It's close to insulting.

I did not want to insult you in any way!

In short it's not a set of macros for 68k.

alright.
so I understand we should not mix up these two ideas and concepts!
no problem.

You want to do the "next gen amiga" properly ?

thats why we are here, isn't it?

Then first we need a cleaned-up cpu. As even though 68k is currently the best, it has its shortcomings, of which only a part can be fixed without going the incompatible way.

fine with me.

Maintaining some kind of compatibility is the one thing we are taking about here - that is where all my talk about emulation belongs. But in the end this is not so important, as we already have a quite good emulator ...

I have no problem with going in a very different direction CPU-wise, being myself a fan of the Mill (which would probably be a terrible beast to program in assembly). Still - some concepts as the protection unit and the support for single address space are worth considering.

Maybe it would also be worth thinking about, if the optimal ISA for the programmer is also the best for the machine - AND wouldn't it be enough if it looks easy for the programmer? (thinking of a more advanced assembler that hides some of the complexity ...)

[jPV]

Originally Posted by Gorf

Why don't they? Attitude? Bad code quality? legal reasons?

It's just that they had to fix/rewrite everything they got from AROS, so a quality issue basically. In the end is was more efficient to write everything from scratch than share and fix.

[Gorf]

Originally Posted by jPV

It's just that they had to fix/rewrite everything they got from AROS, so a quality issue basically. In the end is was more efficient to write everything from scratch than share and fix.

if sharing would have gone both ways.... we would have better code quality in AROS

[meynaf]

Originally Posted by Gorf

Maintaining some kind of compatibility is the one thing we are taking about here - that is where all my talk about emulation belongs. But in the end this is not so important, as we already have a quite good emulator ...

Frankly i don't give a shit about the compatibility. My goal is a machine which would retain the advantages of the miggy while raising it at reasonable performance levels.
Running old programs is already possible with emulation.

Originally Posted by Gorf

Maybe it would also be worth thinking about, if the optimal ISA for the programmer is also the best for the machine - AND wouldn't it be enough if it looks easy for the programmer? (thinking of a more advanced assembler that hides some of the complexity ...)

Hiding the complexity does not remove it.
And this complexity, we could call it entropy, HAS to be located somewhere.
If it's inside the cpu, ok, said cpu will be more complex. But today chips are not that much constrained anymore so it should be manageable.
If it's outside the cpu, then it ends up in programs (even if hidden by using a compiler, it's still there lurking).

At the end, you get the same level of performance in both cases.
If you expense 25% of the energy for executing an instruction but have to execute 4 times more of them to achieve the same result, you get the same power per watt.

So the instruction set does not count very much in theoretical performance (except of course when terrible design mistakes are made).
Except maybe for the fact that per-clock transfer from L1 cache to actual pipeline is quite limited in length and you'd better have a good code density.

It is not uncommon for me to rewrite compiled code and get 4x acceleration (2x if facing a very good compiler maybe, but i still have to see that). Do not trust folks who pretend compilers easily beat asm programmers - it's just wrong. Compilers "win" on some platforms simply because nobody actually challenges them.

In practice, if the cpu is unfriendly to code on, then much less code - if any at all - will be asm. And especially not the most time critical parts.
Furthermore, this "closes" the system and we lose what made Amiga a great machine : a good programmer can enter any program (by disassembling) and make changes in it. Think about whdload slaves for example and imagine what it would have been with an unfriendly cpu - we'd simply not have it at all.

So if at the end the performance level is the same, why not making it programmer friendly ?

[Dunny]

Originally Posted by Gorf

you have a limited number of keyboards with a limited number of keys.
The maximum a single person can handle is probably a arrangement similar to big pipe organ in a church with all the panels and registers.

So yes, you do know what limited options of samples are needed.
You are not going to evaluate different microphone settings of your samples in a live performance - these are things you chose upfront.

Then add VSTs to the mix also. The halting problem tells you that we cannot possibly calculate what resources we will need ahead of time; VSTs are not coded by us.

And... Mic sample mixing is done in-memory for workflow reasons. Imagine the pause every time you undo an action, or load up another 50 samples to mix in!

It's not just performances where a jitter-less workflow is important, you know!

sure you need to have some higher (virtual) sample-rate while calculating the mix - but upscaling should be part of your algorithm. Doubling the value-range to 32bit makes sense - also doubling the rate to 88.2 might be useful - anything more is useless, since all aliasing errors than still left can not influence your hearing experience.

But again: you only need to do that within your calculation, but there is no need to store the instruments in this "quality" since it is only intermediate redundant information.

Again, when actually constructing the instrument it is important that there is no lag, latency or jitter. So even for building such instruments the workflow is important. If there were any of these issues we'd lose professional customers and we can't have that, not even in the name of saving memory - and besides:

Isn't RAM supposed to be used?

with your approach they aren't of course!
first you blow up your data by a factor of >8 without adding information and than you complain about the transfer speed...

Well, quite. It's obvious you don't work in a studio

[Gorf]

Isn't RAM supposed to be used?

No! it wears out so fast - better do not to use!

well - you can fill it with redundant information ... still fail to see this as an advantage.

Well, quite. It's obvious you don't work in a studio

Which is probably a good thing - for me, for the studio and for the rest of the human race.

[kolla]

There's no need for a new ISA for "NG", it's more important to be ISA agnostic and so be able to change CPU architecture quickly when such times come. Like Apple do.

[meynaf]

Originally Posted by kolla

There's no need for a new ISA for "NG", it's more important to be ISA agnostic and so be able to change CPU architecture quickly when such times come. Like Apple do.

What we want here is "like Amiga did".
If what you want is "like Apple do" then get an Apple and leave us alone.

[kolla]

Originally Posted by meynaf

What we want here is "like Amiga did".

"like Amiga did" was to take the best bang-for-buck off-the-shelf CPU of its time and attach custom chipset. It's not like m68k was Amiga exclusive, it was pretty much the norm for all kinds of systems, with the most notable exception being IBM PCs.

[Gorf]

Originally Posted by meynaf

You want to do the "next gen amiga" properly ?
Then first we need a cleaned-up cpu. As even though 68k is currently the best, it has its shortcomings, of which only a part can be fixed without going the incompatible way.

Originally Posted by kolla

There's no need for a new ISA for "NG", it's more important to be ISA agnostic and so be able to change CPU architecture quickly when such times come. Like Apple do.

Well - you are both right.
Even if it looks like opposite opinions or goals.

Actually we need both.

We need to be able to utilize modern processors and gfx in the near future. We should not logger relay on outdated or dead end architecture. Therefor the operating system part must be ISA agnostic - at least for now.
I know, that quite a few, will not recognize such a system as "Amiga" - but without billions of dollars and own ASIC manufacturing, we need to take what is already there to reach good performance levels.

But on the other hand many things in modern PCs (or ARM boards) have gone in the "wrong" direction. Nobody does understand the hardware and the internals of such systems anymore - it is abstraction level over abstraction level. This is why people tinker around with Ardoino so much: it is at least much easier to understand - even if it also has its ugly sides.
A clean, easy to understand, intuitive ISA would be a dream for many developers and advanced users.

Such a new ISA would start as emulation and/or FPGA implementation.

To reach reasonable performance all the suggestions I made for FPGA-assisted dynamic recompilation are still valid. As well for 68k to speed up some kind of emulator, for all retro fans, and also for a new "perfect" ISA.

While CPU-performance is more or less stagnating (per core), FPGAs are still getting faster and better every year - CPU-FPGA-hybrids are definitively a thing to consider and could provide any ISA we like. From the developer and user side such a thing would look like a CPU that can change its ISA on command...

My prediction is, that over time (autogenerated) ASICs will become much more affordable - crowdfunding a CPU with "new perfect ISA" should be around $100K in 5 years.
That would be $100 for 1000 people ...

But until than, we need a (operating) system that can cope with different hardware settings ... so again:
What would be the best candidate for this?
What is conceptional wrong with AROS and could we change that?
Does "FriendUP" have some good ideas?
Is Fuchsia (or parts of it) a candidate?
Could a "OS-Framework" like Genode, QubesOS or a bunch of orchestrated unikernels be the solution?

[kolla]

Originally Posted by Gorf

What is conceptional wrong with AROS and could we change that?

If what you want is a system with the same day-to-day problems that AmigaOS has, then nothing.

Does "FriendUP" have some good ideas?

FriendUP is not an operating system in the conventional sense, it is a "desktop in the cloud", it runs inside your browser.

Is Fuchsia (or parts of it) a candidate?
Could a "OS-Framework" like Genode, QubesOS or a bunch of orchestrated unikernels be the solution?

Yes, yes and yes... but then you are conceptually far, far away from anything Amiga.

There is a vast gap between what so called Amiga developers want and what so called Amiga users want.

[Gorf]

Originally Posted by kolla

If what you want is a system with the same day-to-day problems that AmigaOS has, then nothing.

that is no constructive comment
So i assume you mean it misses features like overall stability and some sandboxing for unstable apps?
What else?
Ist is fixable or do we need something completely different?

FriendUP is not an operating system in the conventional sense, it is a "desktop in the cloud", it runs inside your browser.

I know what it is.
That was not the question.
The question is what ideas does it bring to the table?
Sure I do want a native OS. But I have to admit the Friend got e.g. the looks of the desktop right - better than the other NG-systems or AROS.
Also the comfortable integration of network filesystems and seamless remote desktop applications are nice.

Yes, yes and yes... but then you are conceptually far, far away from anything Amiga.

What are the core concepts, we need to keep?

There is a vast gap between what so called Amiga developers want and what so called Amiga users want.

but still both depend on each other ...

[meynaf]

Originally Posted by kolla

"like Amiga did" was to take the best bang-for-buck off-the-shelf CPU of its time and attach custom chipset. It's not like m68k was Amiga exclusive, it was pretty much the norm for all kinds of systems, with the most notable exception being IBM PCs.

Of course but it had some advantages perhaps even the amiga creators did not foresee... Or at least many users didn't !

Originally Posted by Gorf

We need to be able to utilize modern processors and gfx in the near future. We should not logger relay on outdated or dead end architecture. Therefor the operating system part must be ISA agnostic - at least for now.
I know, that quite a few, will not recognize such a system as "Amiga" - but without billions of dollars and own ASIC manufacturing, we need to take what is already there to reach good performance levels.

This has nothing to do with the operating system. This is about the hardware.
And the hardware should not expose its internal ISA.

Originally Posted by Gorf

But on the other hand many things in modern PCs (or ARM boards) have gone in the "wrong" direction. Nobody does understand the hardware and the internals of such systems anymore - it is abstraction level over abstraction level. This is why people tinker around with Ardoino so much: it is at least much easier to understand - even if it also has its ugly sides.
A clean, easy to understand, intuitive ISA would be a dream for many developers and advanced users.

Such a new ISA would start as emulation and/or FPGA implementation.

All of this is quite obvious.

Originally Posted by Gorf

To reach reasonable performance all the suggestions I made for FPGA-assisted dynamic recompilation are still valid. As well for 68k to speed up some kind of emulator, for all retro fans, and also for a new "perfect" ISA.

If your suggestions are valid, then why not just applying them ?
In short : "just do it".
As we can not be 100% sure it can work this way (and a lot of unexpected problems can come out of it), at least a proof of concept should be made, don't you agree ?

Originally Posted by Gorf

While CPU-performance is more or less stagnating (per core), FPGAs are still getting faster and better every year - CPU-FPGA-hybrids are definitively a thing to consider and could provide any ISA we like. From the developer and user side such a thing would look like a CPU that can change its ISA on command...

From the developer and user side it should remain a black box showing a single ISA that is good enough for hacking in the machine.
The ISA that has to be able to change on command, actually is the internal one.

Originally Posted by Gorf

My prediction is, that over time (autogenerated) ASICs will become much more affordable - crowdfunding a CPU with "new perfect ISA" should be around $100K in 5 years.
That would be $100 for 1000 people ...

That looks optimistic, yet i doubt you'll find 1000 people ready to give $100 away...

Originally Posted by Gorf

But until than, we need a (operating) system that can cope with different hardware settings ... so again:
What would be the best candidate for this?

The trick is to hide these hardware settings behind a common hardware interface so this is not put on the OS's shoulders.
Therefore best candidate is AOS3.x. Because it is lightweight enough and the others are not, because it's the closest to what most amiga users want (i think).
So keep what's good, remove what's wrong, and you're done (mostly).
Several times i've considered starting to rewrite it. But i have not, due to lack of relevant hardware.

Originally Posted by Gorf

What is conceptional wrong with AROS and could we change that?

AROS was born as PC program. And a PC program it'll always remain. Backporting to 68k amigas will not change that.
Take a source at the random and what will you see ? Something amiga specific or a driver for some pc hardware ?

Originally Posted by Gorf

Does "FriendUP" have some good ideas?
Is Fuchsia (or parts of it) a candidate?
Could a "OS-Framework" like Genode, QubesOS or a bunch of orchestrated unikernels be the solution?

Seems you're taking the problem from the wrong side here.
What we need is a good cpu, on which we could write a good OS. I could write one if given a few years and suitable hardware (actually i'm already using my own API on top of AOS for my programs).

We must not use off-the-shelf software or the project is doomed to fail. Because these have not been designed with a specific cpu architecture in mind, they can go everywhere but everywhere they are inadapted.

[Gorf]

Originally Posted by meynaf

This has nothing to do with the operating system. This is about the hardware.
And the hardware should not expose its internal ISA.

fine.
but the hardware is not there yet. So?
classic is slow, outdated and missing too much
Aros is far from ready for daily use - and missing even more.
PPC-NGs are riding a dead horse
I hate Windows.
On Linux I am in control, but honestly it is a pain in the a...
So i am stuck with bloated macOS, which is going downhill last couple of years..

We need a system we can use on modern hardware - best with future hardware in mind.

All of this is quite obvious.

They call me Captain Obvious!

If your suggestions are valid, then why not just applying them ?
In short : "just do it".

No - never said this.
I am not expecting anything being done, besides from myself.
I will probably fail in the attempt ... but thats life.

As we can not be 100% sure it can work this way (and a lot of unexpected problems can come out of it), at least a proof of concept should be made, don't you agree ?

Yes. And that is something I will try. I posted my ideas here to see if there is something obvious wrong, if I missed something crucial that renders all impossible.
Or if it is just something nobody is interested anyways...

From the developer and user side it should remain a black box showing a single ISA that is good enough for hacking in the machine.

understandable request. If the execution is fast enough, that is the way it should be...
(some exceptions could made for the legacy-emulator.
Or some jit-recompile-buffers, that are stored for an app ... but that should not be exposed...)

The ISA that has to be able to change on command, actually is the internal one.

a little bit confused: what do you call extern and what intern?

That looks optimistic, yet i doubt you'll find 1000 people ready to give $100 away...

that would be the chip alone without the board ...
we will see in a couple of years.

The trick is to hide these hardware settings behind a common hardware interface so this is not put on the OS's shoulders.
Therefore best candidate is AOS3.x.

It is not a candidate because of the legal situation. Simple as that.
(That is why I keep on mentioning AROS ... but perhaps we need a fresh rewrite)

So keep what's good, remove what's wrong, and you're done (mostly).

OK.
What is wrong and what is good? Can you make a short list?

Several times i've considered starting to rewrite it. But i have not, due to lack of relevant hardware.

and so the circle closes ...

Seems you're taking the problem from the wrong side here.
What we need is a good cpu, on which we could write a good OS. I could write one if given a few years and suitable hardware (actually i'm already using my own API on top of AOS for my programs).

I have some ideas for the operating system ... or what we could call hardware abstraction and have played around with some stuff.
But it was mainly focused on providing a wider driver basis for Aros-native...

A improved API could be a good thing - something modular and extensible?

I have no clue how to design a good ISA ... so all I could try for now is to improve 68K execution speed, which is only useful for legacy.

[kolla]

Originally Posted by Gorf

that is no constructive comment

There is nothing conceptually wrong with AROS, if what you want is an operating environment with all the same "issues" as AmigaOS.

So i assume you mean it misses features like overall stability and some sandboxing for unstable apps?
What else?
Ist is fixable or do we need something completely different?

It has been repeated for more than 25 years that something completely different is needed. Even Commodore knew this, as they explored using Windows NT for the next gen. Amiga (Hombre+PA-RISC, AAA was still "classic")

The question is what ideas does it bring to the table?

You first have to decide what table you want to sit at, what is it with AmigaOS that you really enjoy and care about? For me, it is the user experience and the workflow that Intuition allows me, with screens, multi-select macros in menus etc. plus the Amiga Shell and for that matter, ARexx. I would very much want to get rid of the entire single address space and move on to a modern and "safe" base, if only I could keep those well known _user interfaces_.

Others however, especially coders, are not so interested in these things, and very much enjoy the single memory space and all the benefits it gives. I have no problems with this, just wish that "most users" would also then recognise that these issues makes it more or less impossible to take Amiga into a modern setting as an "operating system".

But I have to admit the Friend got e.g. the looks of the desktop right - better than the other NG-systems or AROS.

I don't care much about looks, what I would want is to keep the workflow and user experience that I know from Amiga, that is all AmigaOS has to offer that is positively unique.

Also the comfortable integration of network filesystems and seamless remote desktop applications are nice.

Nothing we haven't had before. Did you ever use REBOL?

What are the core concepts, we need to keep?

Depends entirely on who you ask, on the scale from the coders who love to bang hardware, to the users who want a safe modern web browser.

[Gorf]

Originally Posted by kolla

It has been repeated for more than 25 years that something completely different is needed. Even Commodore knew this, as they explored using Windows NT for the next gen. Amiga (Hombre+PA-RISC, AAA was still "classic")

it would have been no good idea to replace it with something much worse like NT...

For me, it is the user experience and the workflow that Intuition allows me, with screens, multi-select macros in menus etc. plus the Amiga Shell and for that matter, ARexx.

Well - Friend offers all that (ok python instead of arexx).
But still it somehow does not count in your eyes?

I would very much want to get rid of the entire single address space and move on to a modern and "safe" base, if only I could keep those well known _user interfaces_.

I have a very different opinion about the single address space.
There is no reason to get rid of it - the system can be made perfectly save and stable with it.
(or do you have any other reasons for separate address spaces?)

Nothing we haven't had before. Did you ever use REBOL?

Carls REBOL - have to admit I never used it and maybe never really understood why I should use it...

Depends entirely on who you ask, on the scale from the coders who love to bang hardware, to the users who want a safe modern web browser.

Both?

[meynaf]

Originally Posted by Gorf

fine.
but the hardware is not there yet. So?

So the hardware has to be made asap.
Else it is putting the carriage before the horse.

Originally Posted by Gorf

classic is slow, outdated and missing too much
Aros is far from ready for daily use - and missing even more.
PPC-NGs are riding a dead horse
I hate Windows.
On Linux I am in control, but honestly it is a pain in the a...
So i am stuck with bloated macOS, which is going downhill last couple of years..

If you're speaking about the OS rather the hardware, then classic may be outdated and missing much, but it ain't slow. On fast hardware it actually flies.

Originally Posted by Gorf

We need a system we can use on modern hardware - best with future hardware in mind.

That will do no good. Current "modern" hardware is under-documented (usually) and very variable (it's close to saying no two machines have exact same config).
Do you really want it to become a mess of drivers ?

Originally Posted by Gorf

No - never said this.
I am not expecting anything being done, besides from myself.
I will probably fail in the attempt ... but thats life.

You still have to do that attempt, because it is the only valid solution.
You have to understand that what's missing the most in the Amiga world isn't software - it is hardware.
Software doesn't wear out - it can wait.

Originally Posted by Gorf

Yes. And that is something I will try. I posted my ideas here to see if there is something obvious wrong, if I missed something crucial that renders all impossible.
Or if it is just something nobody is interested anyways...

Ok then it is maybe time to actually start. I could speak about my cpu design all day long, but i'm rather implementing my vm, assembler and debugger. Maybe i will always keep them for myself. Maybe not. Who knows.

Originally Posted by Gorf

a little bit confused: what do you call extern and what intern?

Intern : the one that executes on actual hardware (x86, arm).
Extern : the one visible to the programmer (68k or better).

Originally Posted by Gorf

It is not a candidate because of the legal situation. Simple as that.
(That is why I keep on mentioning AROS ... but perhaps we need a fresh rewrite)

Yes the solution is the fresh rewrite. It is modular enough for it, and some parts have been rewritten already so we know this is possible.

Originally Posted by Gorf

OK.
What is wrong and what is good? Can you make a short list?

You can get as many lists as people you ask, it wouldn't bring anywhere.
So I prefer to pass on that one. For me it's too early to think about the OS.

Originally Posted by Gorf

and so the circle closes ...

Not so fast. Remember the hardware can first appear as virtual (= emulated).

Originally Posted by Gorf

I have some ideas for the operating system ... or what we could call hardware abstraction and have played around with some stuff.
But it was mainly focused on providing a wider driver basis for Aros-native...

A improved API could be a good thing - something modular and extensible?

AOS is already modular and extensible.
But what it lacks is more "high level" APIs. As currently not much is available directly (without having to open libraries, devices, etc) and there are often several calls where one should suffice.
It also lacks good error handling (many functions just crash with wrong parameters) and resource tracking.
I see it as some kind of "two levels" : a set of APIs that are enough for most programs, and more advanced ones giving the features that are rarely needed (but provide more control).

Originally Posted by Gorf

I have no clue how to design a good ISA ... so all I could try for now is to improve 68K execution speed, which is only useful for legacy.

Then again, just do it. Most of the recipes should still be valid for an enhanced ISA.

[hth313]

Originally Posted by Gorf

But until than, we need a (operating) system that can cope with different hardware settings ... so again:
What would be the best candidate for this?
What is conceptional wrong with AROS and could we change that?
Does "FriendUP" have some good ideas?
Is Fuchsia (or parts of it) a candidate?
Could a "OS-Framework" like Genode, QubesOS or a bunch of orchestrated unikernels be the solution?

I think that what is "conceptionally" wrong with AROS is that it is a clone. If you want an Amiga it is important to start with the genuine code base (3.1) if at all possible.

Perhaps the best start would be a new 68K machine to build a foundation and get (some) steam in the engine. Then try to proceed from there using FPGAs and perhaps an off the shelf CPU. ARM is probably the most sensible choice today, but that is not so important.

The alternative would be to build something that resembles the Amiga experience, using existing code on top of a UNIX. Somewhat like Apple did and there is always DragonFly. We can always look at current macOS and compare that to the old one, it is a step like that. Perhaps the Amiga OS is in better shape than the old macOS and more can be used. Some lessons can probably be drawn from the migration/shift Apple did.

Having a UNIX at the bottom is nice and it solves a lot of problems. Then the question is how much of an Amiga it really is and who it will appeal to. But maybe that is what would do done in the past, maybe there are better ways now?

I am not familiar with Genode and QubesOS so I will not comment on that now. Going towards something different and more modern (UNIX is old) may be an alternative, that would make it different from the mainstream which could be a good thing.

[Megol]

..