SUMMARY OF THIS PRECIOUS, INSIGHTFUL DISCOURSE:

https://youtu.be/uLUIi02FMK0?t=5034

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@Karlos

Quote:

Karlos wrote: @cdimauro Statistical breakdown at this time is a bit meaningless as there's no front end compiler one which to base "real code" examples. It's just a direct assembler syntax to bytecode parser.

Yes, I know it. I was thinking that your architecture is similar to the 68K one, and you might "very roughly" try to translate existing 68K applications to your, to just get some idea on which ballpark you're with real code.
Quote:

The goal was just to provide an assembler experience close to what we remembered, without some of the limitations we preferred to forget.

I think that it's quite common on people interested on computer architectures. I did the same with my 64K rewriting of 68K, long time ago.
Quote:

The compare and branch models how you tend to write code in higher level languages, i.e. "if (a > b) ..."

Indeed. I also introduced similar comparison + conditional branch instructions (but they don't change the flags) on my ISA, for exactly the same reasons. Only that I limited them to general purpose and mask (for SIMD/vector code) registers, and not for the FPU/SIMD/vector ones.
Quote:

It's not intended as a VM for general use, it's more for nostagic purposes.

I see. Same thing for my previous architectures.

However for the last one I had more serious goals, and I'm still trying to purse them.
Quote:

I did develop a number of other VM for other purposes: ExVM was a 16-register load/store general purpose embeddable VM with better code density and higher overall interpreter throughput. It was designed originally to allow cross platform self decoding data formats and simple scripting tasks. I used it in some of my C++ framework code, allowing binary files saved on one architecture to import into a different one without explicit awareness of the data layout. It was highly portable with 68K, PPC, x64 and ARM implementations. See https://github.com/0xABADCAFE/exvm

That's much better from the code density PoV. I also looks much more complete.

You might improve it on some areas, using the extended word instructions opcodes:
- pack unary (two registers: source + destination) instructions on a single opcode, using the 8 bits which are currently zero on the second word. This should free several opcodes;
- pack binary (three registers: source 1 + source 2 + destination) instructions on a single opcode, using the 4 unused bits which are currently zero on the second word. This should free several opcodes;
- introduce binary (2 sources + destination) instructions for the general purpose and FPU instructions. This will allow you to make non destructive operations, without requiring two instructions (so, reducing the number of executed instructions);
- introduce SIMD/vector instructions.

However I don't like L/S architectures. Albeit it's not a "pure" one (since it's variable-length, and some istructions have with immediates).
Quote:

Another was StackGVM. This was completely different to either of the above. It was intended to provide a basic script host for a 2.5D game engine I was working on at the time. It was intended to be directly compiled from a C style language with function parameters, locals and return values. In contrast to either of the above, it had 32-bit integer/float/address only, as well as explicit 2D and 3D vector primitives of 32-bit floats. It had no user registers and used a stack frame layout in which every function reserved space for its parameters, returns and locals and parameters for a child call. These were all accessed as signed 8 bit displacements from the base stack address of the call. Negative values allowed for anonymous closures to refer to variables in the calling scope. By limiting the number of allowed locals (80 or so IIRC), you always had enough space to parameterise another function call from the current scope. This whole approach eliminated a lot of stack management and copying. See: https://github.com/0xABADCAFE/random-junk/tree/master/stackgvm (TOYTL stands for Thirty Odd Years Too Late) This one was a curious design journey. There's more info here (Google Doc)

Unfortunately there's no document describing the opcodes structures and instructions, so it difficult get an idea of the ISA.

BTW I don't like stack-based architectures as well. They are very compact, providing excellent code density, but they are not so general-purpose, require more instructions to do the same work, and they are difficult to program for codes.

For those reasons I've added an opcode format to "translate" to binary (3 operands) all legacy x87 instructions, getting rid of the issues of this old FPU unit on x86/x64.

@Nonefornow

Quote:

That's what Guy Kawasaki says all the time - "Not worry be crappy". Send the OS out and then upgrade later.

Ha.

@cdimauro

Quote:

A-EON didn't need to rewrite OS4 components from scratch: AROS sources are publicly available and they could have borrowed them for this purpose, making only the needed changes for support OS4.

They don't need too but it looks like they are. I don't know if they are outsourcing but they would need some kind of agreement if using open source code like AROS in commercial software. Or just grab the code freely and privately make changes.

I should do a test of AROS components. And see how the Version command reacts. A faulty Version (if you excuse the pun) will return a false positive when looking for "MorphOS" when not on MorphOS.

Being MorphOS shares some AROS code it would be interesting to compare it with the A-Eon OS4 Version.

@cdimauro

Quote:

That's simply not true.

Oh sorry, I completely forgot you must know better than me!

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

@cdimauro

ExVM
Quote:

That's much better from the code density PoV. I also looks much more complete.

Note that some of the unused bytes are due to the instruction stream being 16 bit aligned. The PDF documents are somewhat incomplete (so much work lost due to a lax attitude to backups). It also has a whole bunch of vector extension set that do block operations on data. Given it was used to allow, for example, some custom image data format to decode itself to a regular pixel map, these were useful. I was a bit less security conscious then. The idea of "embedded datatypes" seemed good back when I first had the idea. It's pure poison now, lol. Nevertheless, as a general purpose VM for scripting purposes it was reasonably performant.

GVM
Quote:

Unfortunately there's no document describing the opcodes structures and instructions, so it difficult get an idea of the ISA.

Generally, bytecode. 4 bytes per operation. One byte opcode, followed by 3 bytes for operands.

The opcode indicates the action, type (int/float/vec3) and access variant. The access variant is typically one of up to seven distinct variations based on which of the operands should be interpreted as a local stack frame offset or an indexed source or destination pointer dereference. Only a maximum of two operands can ever be an index pointer. This allows for data structures to be directly read and written without having to go via the stack. The idea is that the data structures shared between the host engine and VM are all just effectively varying length arrays of 32-bit words when you get right down to it. This is why there's no endian considerations at all.

Some instructions are shorter but 4 bytes each is typical.

As a soak test, I ported Andrew Kessler's Business Card Raytracer to it as it was a great test of both scalar and vec3 operations.

Last edited by Karlos on 09-May-2022 at 09:57 AM.
Last edited by Karlos on 09-May-2022 at 09:13 AM.

_________________
Doing stupid things for fun...

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: A-EON didn't need to rewrite OS4 components from scratch: AROS sources are publicly available and they could have borrowed them for this purpose, making only the needed changes for support OS4. They don't need too but it looks like they are. I don't know if they are outsourcing but they would need some kind of agreement if using open source code like AROS in commercial software. Or just grab the code freely and privately make changes.

No, it's very simple: everyone can do whatever he/she wants with AROS sources, with only one constraint: release the sources with the changes if you publish products which used them.
Quote:

I should do a test of AROS components. And see how the Version command reacts. A faulty Version (if you excuse the pun) will return a false positive when looking for "MorphOS" when not on MorphOS. Being MorphOS shares some AROS code it would be interesting to compare it with the A-Eon OS4 Version.

I don't think that A-EON is planning to release its sources, even for those simple command-line tools.


@Trixie

Quote:

Trixie wrote: @cdimauro Quote: That's simply not true. Oh sorry, I completely forgot you must know better than me!

No, you simply forgot elementary logic.

In fact, I've reported FACTs. And facts can be either true or false.

If you think that they are false, you're free to rebut them.

Isn't that simple?

But you haven't done it!

I don't know if you're an OS4/Hyperion developer, but if this applies then you felt down to a common logical fallacy: Argument from authority .

You can be such a developer, or even a Nobel Prize, but you have no privilege of confuting people only with some words: your words have the same value as mines. Unless you prove the contrary...


@Karlos

Quote:

Karlos wrote: @cdimauro ExVM Quote: That's much better from the code density PoV. I also looks much more complete. Note that some of the unused bytes are due to the instruction stream being 16 bit aligned. The PDF documents are somewhat incomplete (so much work lost due to a lax attitude to backups). It also has a whole bunch of vector extension set that do block operations on data. Given it was used to allow, for example, some custom image data format to decode itself to a regular pixel map, these were useful. I was a bit less security conscious then. The idea of "embedded datatypes" seemed good back when I first had the idea. It's pure poison now, lol. Nevertheless, as a general purpose VM for scripting purposes it was reasonably performant.

OK, I see. And I think you have no plans to further expand it: looks like an old project now.
Quote:

GVM Quote: Unfortunately there's no document describing the opcodes structures and instructions, so it difficult get an idea of the ISA. Generally, bytecode. 4 bytes per operation. One byte opcode, followed by 3 bytes for operands. The opcode indicates the action, type (int/float/vec3) and access variant. The access variant is typically one of up to seven distinct variations based on which of the operands should be interpreted as a local stack frame offset or an indexed source or destination pointer dereference. Only a maximum of two operands can ever be an index pointer. This allows for data structures to be directly read and written without having to go via the stack. The idea is that the data structures shared between the host engine and VM are all just effectively varying length arrays of 32-bit words when you get right down to it. This is why there's no endian considerations at all. Some instructions are shorter but 4 bytes each is typical.

Understood, thanks. It's still difficult to get an idea of how good can be the code density, but this looks VM highly specialized, and maybe a comparison with some ISA doesn't make sense.

Is the the opcode granularity in bytes or words (16-bits)?
Quote:

As a soak test, I ported Andrew Kessler's Business Card Raytracer to it as it was a great test of both scalar and vec3 operations.

I saw in the documentation that this was the area of interest. Well, I also saw your YT channel, and this is even more evident.

@cdimauro

lol, we should probably have a different thread for this...

Ok, here...

Quote:

OK, I see. And I think you have no plans to further expand it: looks like an old project now.

One of the things about being "on the spectrum" is that you can't let go of ideas easily. So as unmoving as it is, the day will surely come when I decide I want to work on it. It wasn't a terrible design and I think it has potential as a generalised scripting target.

Quote:

Understood, thanks. It's still difficult to get an idea of how good can be the code density, but this looks VM highly specialized, and maybe a comparison with some ISA doesn't make sense. Is the the opcode granularity in bytes or words (16-bits)?

StackGVM was a pure bytecode machine. Instructions vary between 1-6 bytes in length, most arithmetic and logic instructions are three operand.

My original idea was that it would be a register based machine but after a first design pass, I became dissatisfied with it given the need to support 3 component vectors which would tend to be accessed indirectly too. The register machine did support some local stack operations too by which point I had an epiphany that a much simpler "stack frame" model was possible. In the end, it was.

The code density is not as high as other designs, however, the types of operations implemented in it are largely short functions that benefit from having the shortest sequence of discrete operations. With effectively up to 128 function-scope variable slots to play with (that includes your own parameters, return, locals and the return/parameter space of any child calls) and three operand instructions, you can get a lot done in just a few steps. And as you say, it's highly specialised for a particular use case.

Quote:

Well, I also saw your YT channel, and this is even more evident.

Feel free to like and subscribe I make no apologies for torturing PHP and terminals...

Last edited by Karlos on 09-May-2022 at 08:22 PM.

_________________
Doing stupid things for fun...

@cdimauro

I think I can clear things up here a little bit. The legal situation between Cloanto and Hyperion has made Amigakit totally redo the OS from scratch. On top of that, the new technology introduced by the new graphics subsystem has further complicated things.This has happened to the point that the new command line applications have caused a considerable amount of confusion among Enhancer users. The fact they are also a little buggy hasn't helped either. a lot of what V54 will be can be found in Enhancer 2.1.

Why did they not just use Aros components when they easily could of? My answer us that Amigakit's coders felt they could write better code. They were probably right.

System V54 is probably Enhancer software wrapped around an advanced Linux kernel. I know for a fact that Team Core Linux have been testing and working with some very advanced Linux software. What does this mean? For one thing, you will use 54 like you would use AmigaOS. You will not need to access the Linux kernel at all. It will work very similar to how a Mac works. The new graphics system will allow full use of Radeon's advanced graphics card. This will allow the full use of multiple monitors for example. Coders will be able to basically code as they would with AmigaOs, unless they need to do low level coding.

I have tried to briefly state what I believe V54 is about. I have been following the development since Enhancer 1. V54 is not a johnny-come-lately It has been actively developed since 2015.. It has bee years in the making.

As to the hardware it will run on, other than the current ppc computers, I won't comment at this time.

@Neuf

perhaps they write "better code" but still it makes sense to concentrate on important parts and not rewriting simple shell commands. But everybody to its own. And open source only means to give back changes for the benefit of all, not to open everything. Even MorphOS at least in the past used aros sources.

System54 is a wrapper around a linux kernel? That is new to me. There is of course activity regarding linux (in fact most activity right now if you look in forum) but that the whole system is linux based is completely new to me.

Last edited by OlafS25 on 09-May-2022 at 08:46 PM.
Last edited by OlafS25 on 09-May-2022 at 08:00 PM.

@all

not OS4 but at least looking like

this is Aros with Scalos and OS4 Theme on 68k:
http://www.aros-platform.de/Scalos_OS4.png

and this Aros with Scalos and OS4 theme on X86:
http://www.aros-platform.de/Scalos_OS4_X86.png

@OlafS25

The problem Olaf, is that because of the legal situation everything and I mean everything had to be redone.There was no possibility of letting the OS4 commands stand.

System V54 is not the only thing A-EON has going on behind closed doors. A-EON has a quite extensive R&D program on Linux which has accomplished quite bit--only not on the market yet. I expect some of the things they are doing to show up in54 but quite a bit will stay locked up.

@Neuf

OK sounds mysterious

hopefully something useful comes out from it

@Neuf

Quote:

Neuf wrote: @OlafS25 The problem Olaf, is that because of the legal situation everything and I mean everything had to be redone.There was no possibility of letting the OS4 commands stand.

There are also other reasons why this effort might make sense.
There is no one really working on OS4 in any capacity anymore and A-EON has no access to any of the sources for many of these commands.

In order to fix any small bugs that might show up and interoperate poorly with Enhancer they would have to re-write them from scratch. Otherwise, how are they going to maintain and fix bugs in the system? Hyperion for sure no longer has anyone working on maintaining the codebase.
There are no OS4 developers either.

Just from a "we want to ship something that can be supported and maintained" as a hobby-scale commercial product kind forces A-EON to rewrite it all from scratch.


Just a thought on additional reasons to do this than the VERY sane reason to "lets not enter any kind of legal or commercial agreement ever again with Hermans"


Back to @ppcamiga1 and porting OS4 to x86. Why? There are no application on OS4 that needs the power you get on modern machines. People that want a new OS4 machine can just buy a ppc board. Unless tabor ever is released, as long as A-Cube can release a small batch of SAMs every few years that is enough hw to fully service the entire market perpeptually. Porting to x86 makes no sense and is imho a waste of resources that they don't have in the first place anyway.

Last edited by V8 on 10-May-2022 at 04:39 AM.

@Neuf

Quote:

Neuf wrote: @cdimauro I think I can clear things up here a little bit. The legal situation between Cloanto and Hyperion has made Amigakit totally redo the OS from scratch. On top of that, the new technology introduced by the new graphics subsystem has further complicated things.This has happened to the point that the new command line applications have caused a considerable amount of confusion among Enhancer users. The fact they are also a little buggy hasn't helped either. a lot of what V54 will be can be found in Enhancer 2.1.

This I've understood, but I've my doubt that this operation makes sense.

OS4 is a sinking platform, and A-EON knows it. They already said here, in the past, that salaries for families come from "classics".

To me this V54 project looks like committing a suicide.
Quote:

Why did they not just use Aros components when they easily could of? My answer us that Amigakit's coders felt they could write better code. They were probably right.

I've found AROS code to be goodly written.

Maybe they didn't like the macros used for functions signatures, but you can get quickly used to them.
Quote:

System V54 is probably Enhancer software wrapped around an advanced Linux kernel. I know for a fact that Team Core Linux have been testing and working with some very advanced Linux software. What does this mean? For one thing, you will use 54 like you would use AmigaOS. You will not need to access the Linux kernel at all. It will work very similar to how a Mac works. The new graphics system will allow full use of Radeon's advanced graphics card. This will allow the full use of multiple monitors for example. Coders will be able to basically code as they would with AmigaOs, unless they need to do low level coding.

I doubt that V54 is Linux-based, or uses Linux in general.
Quote:

I have tried to briefly state what I believe V54 is about. I have been following the development since Enhancer 1. V54 is not a johnny-come-lately It has been actively developed since 2015.. It has bee years in the making. As to the hardware it will run on, other than the current ppc computers, I won't comment at this time.

It has to be a big-endian system, otherwise the transparent 68K emulation doesn't work.


@Neuf

Quote:

Neuf wrote: @OlafS25 The problem Olaf, is that because of the legal situation everything and I mean everything had to be redone.There was no possibility of letting the OS4 commands stand. System V54 is not the only thing A-EON has going on behind closed doors. A-EON has a quite extensive R&D program on Linux which has accomplished quite bit--only not on the market yet. I expect some of the things they are doing to show up in54 but quite a bit will stay locked up.

So, the legal situation prevents Hyperion to continue ITS business with OS4 (which wasn't Cloanto business), but doesn't prevent to start a completely new business with OS 3.1.4/3.2 (which is Cloanto's business)?

Do you really believe it?

@V8

Quote:

V8 wrote: @Neuf Quote: Neuf wrote: @OlafS25 The problem Olaf, is that because of the legal situation everything and I mean everything had to be redone.There was no possibility of letting the OS4 commands stand. There are also other reasons why this effort might make sense. There is no one really working on OS4 in any capacity anymore and A-EON has no access to any of the sources for many of these commands. In order to fix any small bugs that might show up and interoperate poorly with Enhancer they would have to re-write them from scratch. Otherwise, how are they going to maintain and fix bugs in the system?

So V54 is just for maintenance: no goal to rewrite everything. This looks much better.
Quote:

Hyperion for sure no longer has anyone working on maintaining the codebase. There are no OS4 developers either.

Strong statement is your. How to you know it?
Quote:

Just from a "we want to ship something that can be supported and maintained" as a hobby-scale commercial product kind forces A-EON to rewrite it all from scratch. Just a thought on additional reasons to do this than the VERY sane reason to "lets not enter any kind of legal or commercial agreement ever again with Hermans"

I fully agree.
Quote:

Back to @ppcamiga1 and porting OS4 to x86. Why? There are no application on OS4 that needs the power you get on modern machines. People that want a new OS4 machine can just buy a ppc board. Unless tabor ever is released, as long as A-Cube can release a small batch of SAMs every few years that is enough hw to fully service the entire market perpeptually. Porting to x86 makes no sense and is imho a waste of resources that they don't have in the first place anyway.

Correct.

@cdimauro

Quote:

No, it's very simple: everyone can do whatever he/she wants with AROS sources, with only one constraint: release the sources with the changes if you publish products which used them.

Yeah. Nah. Thay ain't going to do that. They don't want open sources. They want to keep it private. And be able to edit it

Quote:

I don't think that A-EON is planning to release its sources, even for those simple command-line tools.

No, but again, why? Neither A-EON nor AmigaKit produce OS4. It's not their OS. They write software and produce drivers for it. Since FE there has been some kind of symbiotic relationship as OS4 needs Enhancer software to fully function and Enhancer needs OS4 to work.

Of course, when it comes to producing a boot CD, I can see why. Since FE cannot boot with newer hardware nor is a boot CD/USB image creator included. Ðespite OS3.9 having one for floppy.

But even before the System54 boot creator is available, there is now a divide in the OS4 community, with AmigaOS 4 and EnhancerOS 4.

@Neuf

Quote:

The problem Olaf, is that because of the legal situation everything and I mean everything had to be redone.There was no possibility of letting the OS4 commands stand.

But why redo it? It already exists! It's not their OS and despite needng to write from scratch over 20 years of code, what right do they have to do so? It won't be original. It will be a copy of AmigaOS and at that point rather pointless to keep dragging their heart around on PPC again. OS4 is not abandonded.

Quote:

System V54 is not the only thing A-EON has going on behind closed doors. A-EON has a quite extensive R&D program on Linux which has accomplished quite bit--only not on the market yet. I expect some of the things they are doing to show up in54 but quite a bit will stay locked up.

Would be good if they investigated how to make Linux boot easier with an auto boot CD or USB and OS menu. I'm the only I know whose done it! At least in the XE and X1000.

Last edited by Hypex on 10-May-2022 at 05:59 PM.

@V8

Quote:

There are also other reasons why this effort might make sense.

They are secretly working on an Arm SoC that will be hanging on mantles at Chrismas time!?

Quote:

There is no one really working on OS4 in any capacity anymore and A-EON has no access to any of the sources for many of these commands.

So what? Why do they need access? That's rather rude!

Anyway, OS4 is still being worked on, just like it has been. OS4 development hasn't stopped. I get emails about it every day.

Quote:

In order to fix any small bugs that might show up and interoperate poorly with Enhancer they would have to re-write them from scratch. Otherwise, how are they going to maintain and fix bugs in the system?

It's not their system to fix. They can code a work around. And submit a bug report. That doesn't mean it will be released in the next uddate. But this is the world I live in and so do all OS4 users.

But, I had to reduce Enhance components on my system, as it had the opposite effect. It introduced bugs. Which were the result of not using OS4 system components.

Quote:

Hyperion for sure no longer has anyone working on maintaining the codebase

Baloney!

Quote:

There are no OS4 developers either.

Ha!

Quote:

Back to @ppcamiga1 and porting OS4 to x86. Why? There are no application on OS4 that needs the power you get on modern machines. People that want a new OS4 machine can just buy a ppc board. Unless tabor ever is released, as long as A-Cube can release a small batch of SAMs every few years that is enough hw to fully service the entire market perpeptually. Porting to x86 makes no sense and is imho a waste of resources that they don't have in the first place anyway.

Actually yes there is and it's right in front of you. Browsing! The browsers may not be up to scratch but browsing on OS4 is too slow. Facebook used to be ok on my X1000 but now days that's almost impossible and even AmigaWorld is slow! Despite being an old forum. Videos look like Doom on the Amiga but worse. So yes it needs power.

Compiling, rendering, video or any other CPU intensiuve works needs power.

Apart from that it needs to be afordable. So the point isn't really about power. It's just that the best power is also the cheapest. The X1000 dual core CPU is wasted on OS4 but an older single core could have been more expensive to source. For the price now, they might as well target Power9, because it brings power at a price closer to what that are asking for an X5000.

Last edited by Hypex on 10-May-2022 at 06:02 PM.

Maybe someone should port OS3.1 to PowerPC.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@thread

Couldn't the new Amiga company have this System 54 ported to the pi or even their own custom arm based system & rename it Amiga Os 5.

Surely its time to move on from Os4. when they brought out "final edition" I thought the next step would be Amiga Os 5.