@kolla

You suggested on another thread that when the THE A500 Maxi comes out you should replace the main board with an AMD one. I'm going to go one step further. I will not only do that, but will also install Windows and the RGL WIDE on the computer. I will then do all my coding on the Maxi. Could I then say that I'm doing all my Amiga coding on a real Amiga?

RGL is certainly supporting us C64 coders with pretty good support and I expect the same will be true for THEA500. I thought that what I proposed above was not a bad idea.

cdimauro Quote:

Emulation has much less chances to fail compared to all other alternatives. WinUAE clearly proven it. But much better can be done with a "virtualizer", like I've said before.

It matter how success or failure is measured. Compilers and software generally don't target WinUAE. They target real Amiga hardware even though it is older and low spec. WinUAE is only a success because of the real Amiga hardware. It wouldn't exist without real Amiga hardware and would disappear quickly if it was not compatible with it. Some forum users have talked about doing away with compatibility making it a virtual machine only as it would not be emulating real hardware. Virtual machines have largely been a failure due to lack of competitiveness except out of necessity. The Java Virtual Machine (JVM) using byte code had some success and became a developer target but it also had some hardware acceleration like Jazelle extensions in ARM CPUs and a few hardware Java processors.

https://en.wikipedia.org/wiki/Jazelle
https://en.wikipedia.org/wiki/Java_processor

Other attempts like Tao Intent as used in Amiga Nowhere have mostly been abysmal failures.

https://en.wikipedia.org/wiki/Tao_Group

I see benefits for emulating real hardware which can be useful despite being inefficient but virtual machines are a waste of time and what I refer to as a failure.

cdimauro Quote:

But you cannot fix frontend or backend issues. Even because microcode use is quote limited, and for good reasons: most of the executed instructions use no microcode, and that's the reason why they are so fast.

It's amazing what can be fixed which is expanding. The major Intel hardware bug allowing the Meltdown exploit was fixable in more modern Intel CPUs with minimal performance loss while earlier CPUs had significant performance losses.

cdimauro Quote:

How? It's not clear from the document that you provided.

eFPGA blocks could give FPGA functionality in a device. This could allow the flexibility of FPGA functionality with the performance, low power and low cost of an ASIC. FPGA chipsets, codecs and other specialized parallel code could be loaded into eFPGA blocks as needed. The FPGA chipsets would not have to go through the extensive verification and testing like the CPU core thus saving time. The 68000 use of microcode and the Amiga 1000 use of WCS/WOM for kickstart show the advantage of flexibility that allowed these products to get to market quicker. FPGA functionality is valuable for embedded and educational uses as well.

cdimauro Quote:

No. The clear target for Vampire is assembly programming (and direct hardware hitting). There's no doubt about it, according to the several times that it was repeated by Gunnar or some other Vampire member. For this reason, an assembler (and disassembler) is enough: no high-level compilers support is required. And for the same reason the Vampire will be limited to a niche. Which isn't unexpected, BTW...

How useful is an ISA optimized for FPGA cores and assembly programming? Shouldn't ISAs be optimized for ASICs and compilers instead?

cdimauro Quote:

The thing is very simple: Gunnar likes to decide everything, because the project is essentially his own. He has some ideas about what Vampire should be, and he's pursuing his direction.

Is it? Gunnar borrowed Thomas's Natami SAGA and Jen's N68k core. Gunnar provided the determination to keep developing their projects past the point of sanity is all.

cdimauro Quote:

And I've nothing to say about it, because I would have done the same if I had his expertise and chance. And you know why? Because, at the very end, he was able to deliver! Deliver a product to people who like exactly what he proposed to them. When I was at Intel I've learned a simple but quite effective mantra which is circulating on the company: deliver is the king! And with this mindset we worked. And delivered. And achieved success. And gained market.

Yes, Gunnar delivered something that a few thousand Amiga users like. When Gunnar e-mailed me asking me to join the Apollo Team, he wrote, "all what we wanted to do we reached now". He didn't deliver to me and I don't think I'm alone. Setting low goals is a good way to achievable them.

cdimauro Quote:

I think that, as computer architecture passionate people, we recognize mistakes and bad design decisions which Gunnar made with the 68080 (and SAGA too, if we want to extend a bit the topic). But think about it: what could have happened if you were the 68080 designer and you delivered the product according to your vision? Do you think that nobody could have criticized it / your work?

That's why asking for input from developers giving them a chance to come up with improvements before making consensus group decisions is a good idea. Data from suggestions should be analyzed of course. It is not possible to please everyone but having ideas rejected by a group majority is reasonable and easier to understand.

cdimauro Quote:

How many times have we (me, you, megol, Gunnar, etc.) discussed about ISA (and chipset) topics? How many times we had different ideas and disagreed? Countless... Because this is the reality: everyone has HIS vision about how a certain ISA should be designed and implemented. And it's VERY DIFFICULT to find a common agreement. Impossible, I would say, after so much discussions.

Gunnar's ISA with all the banks of registers and bolt-ons is not unprecedented. It reminds me of the somewhat 68k like StarCore DSP.

https://www.nxp.com/docs/en/reference-manual/MNSC140CORE.pdf

It's not general purpose although there are DSPs which are more difficult to program and write a compiler for (it is difficult for a compiler to take advantage of many of the features as with the Apollo ISA). Compiler support has to be one of the primary goals. My primary goals for a 64 bit ISA would probably be something like the following.

1. easy to use by compilers
2. similar to existing 68k code with similar ease of use
3. best code density for a general purpose 64 bit ISA

Gunnar's ISA goals would be something like the following.

1. optimize for FPGA performance
2. add as many registers as possible and bolt on anything needed wherever it fits
3. easy to use by assembler programmers

Gunnar talked like my priorities were important too but then prioritized his own.

cdimauro Quote:

At least Gunnar was able to deliver. Kudos to him! For this reason I think that we should separate the two things, and don't mix them. One thing is our evaluation about ISA, chipset, and whatever technical topic. Another thing is the products on the market. To be more clear, finger pointing Gunnar for what he did doesn't make sense: those are pointless complaints (here I also see a little bit of envy, eh! I also envy him because he produced something which I wasn't able to do). So, let's limit our analysis to the technologies which were delivered and/or about how personal vision of how things should be done.

I don't envy Gunnar. I am more objective about it. He sabotages his own project which the team, including him, worked so hard at. I feel sorry for him but not as sorry as I feel for Jens and Thomas who did everything right except let Gunnar be in charge. I do have a good reason to talk about it because I was part of it.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Trixie From what I have read on Amiga.org, some places there where some small changes to some of the commands, not sure what, I don’t remember, no one compiled a list of this problems Kolla found. And not sure everyone will agree that are actual bugs.

Some o.s. 3.x developers agreed (failat, the more notable example) that they are bugs, and this should be enough.

O.s. 3.x developers should seriously consider asking kolla testing their software, since he's good as QA engineer.


@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Karlos I think the problem with that idea, is that you trying to force, MC680x0 code into becoming something it was never was intended for, what is the standard for MC680x0 Amiga assembler code exactly.

If it wasn't intended before it doesn't mean that it isn't good for.

You should only evaluate if a new idea (about an old project, in this case) is good or not, making a list of pros and cons and weighting all.
Quote:

Some time you bang the hardware, sometime you can’t, sometime you take over the OS, and sometime you can’t,

Different use cases require different tools.

O.s. friendly applications -> JIT/AOT (better) compiler / virtualizer.
Games & o.s. unfriendly applications -> WinUAE (EUAE for the unlucky cousins) is the right tool.

A user generally does one thing at the time: use applications or games. But even when deciding to pass from one to another type of applications, changing the context is not expensive (and this scenario can also be improved: transparently executing UAE when launching a game, for example, and then going back when it's done).
Quote:

while MC680x0 is shared between MOS PPC, AOS PPC, AROS 68K, AOS 68K, Amitlon the ABI is somewhat not standardized. (Naturally native ABI is faster, not sure all new stuff is available on the EMU 68K ABI, or if that only in native ABI of AmigaOS4.x ppc.)

You don't need a new ABI here: just use 68K + Amiga o.s 3 AKA the (last) Amiga platform as the common base. But without the chipset: not strictly required (chipset-specific stuff is UAE domain) because AHI and RTG were already available for Amiga and they can be used for applications.

In short: Amiga is the common ground for all post-Amiga o.ses. This is/was the point.

For this reason you might need to backport to 68K some applications which are exclusively available for other platforms. Just to consolidate this (already) big software library.
Quote:

Tools made to make WHDLOAD games, and ADF’s games with boot loaders, people continue to write OCS/AGA demos, the adoption of RTG/P96/CGX is slow. I think some action from 68K community as defiance agents the NG systems. The other part is old tools to make games and demos, that’s not up to date. Its not the OS that problem its community and slow adaptation of RTG, and lack of developers to maintain and update the software. Even worse who do you fix a 20-year-old program, there is no source code for, who be interested in disassemble and writing patches, rewriting or replacing old tools?

You already mentioned WHDLoad, and you should know that around FOUR THOUSANDS of games were already available in this "format". Not even counting the demos.

And you should know that games are MUCH harder to be fixed compared to applications, right?
Quote:

What language will choice. Do you think 68k assembler or C/C++?

Your question simply doesn't make sense: use whatever language that you want. As long as 68K/Amiga (hunk) binaries are generated.


@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Karlos I wonder if not Web assembly or LLVM or something like be better, Emulating of really low-level stuff like flags, or interrupts, mmu’s and FPU, does it make sense? Wont be better to abstract that, let middle ware take of that. I think creating our own programming language, that takes care of endianness can be a why to approach this, this why write this or that why, know what format its written, it be easy to know when you need to convert something, and if you have be endian CPU, you ca use best opcode to handle it. I think its shameful that was not already done in C/C++. What a sec, Hollywood programming language does this more or less, at least has become a why to make portable Amiga programs.

As per the above and per Karlos reply, this also doesn't make sense.


@Neuf

Quote:

Neuf wrote: @kolla You suggested on another thread that when the THE A500 Maxi comes out you should replace the main board with an AMD one.

This will make the platform more expensive, compared to a RPi or some cheap ARM SoC.
Quote:

I'm going to go one step further. I will not only do that, but will also install Windows and the RGL WIDE on the computer. I will then do all my coding on the Maxi. Could I then say that I'm doing all my Amiga coding on a real Amiga?

Real Amigas (according to Commodore's Amiga Hardware Manual, which clearly and precisely defined what an Amiga was) aren't available anymore. So, the answer is no.

But your system will be similar to the Pegagos and SAM computers, which allowed to run AmigaOS4. Those computers hadn't "The Name" (AmigaOne, in this case. Amiga, as I've said, is another thing), but are considered as "Amigas" by their users.

To sum it up: as long as you run some Amiga software (which is the only thing left and really important for users), call "Amiga" whatever is your system.
Quote:

RGL is certainly supporting us C64 coders with pretty good support and I expect the same will be true for THEA500. I thought that what I proposed above was not a bad idea.

What's RGL?

@cdimauro

Quote:

What's RGL?

https://thec64community.online/thread/426/rgl-thec64

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@matthey

Quote:

matthey wrote: cdimauro Quote: Emulation has much less chances to fail compared to all other alternatives. WinUAE clearly proven it. But much better can be done with a "virtualizer", like I've said before. It matter how success or failure is measured. Compilers and software generally don't target WinUAE. They target real Amiga hardware even though it is older and low spec. WinUAE is only a success because of the real Amiga hardware. It wouldn't exist without real Amiga hardware and would disappear quickly if it was not compatible with it.

WinUAE is here to stay as long as the sources are available.

Yes, it didn't existed without the real hardware, but now that the real hardware doesn't exist anymore it's the best (and maybe only) way to broadly (as audience) make use of the Amiga software.
Quote:

Some forum users have talked about doing away with compatibility making it a virtual machine only as it would not be emulating real hardware. Virtual machines have largely been a failure due to lack of competitiveness except out of necessity. The Java Virtual Machine (JVM) using byte code had some success and became a developer target but it also had some hardware acceleration like Jazelle extensions in ARM CPUs and a few hardware Java processors. https://en.wikipedia.org/wiki/Jazelle https://en.wikipedia.org/wiki/Java_processor Other attempts like Tao Intent as used in Amiga Nowhere have mostly been abysmal failures. https://en.wikipedia.org/wiki/Tao_Group

Not all VM are failures. Java is an example, but C# is even better. It depends on how the VM (ISA, for the major part) is designed and then implemented.

If you take a look at Karlos' MC64K ISA, for example, you can clearly see that it was designed (I refer to the opcodes structure) to have it easily emulated in software -> create a very efficient VM for it (and likely an efficient JIT).
However, and due to the same design decisions, it's difficult to be implemented in hardware (very similar to the VAX ISA issues, from this PoV), and not well suitable for real code due to not good code density (this is my guess looking at opcodes, of course).
Pros and cons: that's the real world! A design comes the synthesis of several requirements & constrains.

Whereas if you take a look at the 68K ISA, we know that it's difficult to be implemented in hardware, emulated, and also implemented as a VM as well. But at least emulation (JITs) and VMs can be improved by tracing the 68K instructions execution and making it much easier to quickly generate and execute (more optimized) code in the native / host platform. Hard work, to mitigate the 68K's clumsy design decisions...
Quote:

I see benefits for emulating real hardware which can be useful despite being inefficient but virtual machines are a waste of time and what I refer to as a failure.

"Failure is as failure does" (cit.).

Failures should be at least "measurable", do you agree?

Where are the failures on VMs? How did you measure them?
Quote:

cdimauro Quote: How? It's not clear from the document that you provided. eFPGA blocks could give FPGA functionality in a device. This could allow the flexibility of FPGA functionality with the performance, low power and low cost of an ASIC. FPGA chipsets, codecs and other specialized parallel code could be loaded into eFPGA blocks as needed. The FPGA chipsets would not have to go through the extensive verification and testing like the CPU core thus saving time. The 68000 use of microcode and the Amiga 1000 use of WCS/WOM for kickstart show the advantage of flexibility that allowed these products to get to market quicker. FPGA functionality is valuable for embedded and educational uses as well.

So basically it's like what Intel is selling since some years with some Xeon's with embedded FPGA from (ex) Altera. You have the regular CPU cores with some FPGA blocks embedded, which can be (re)programmed to simulate additional things (like a chipset).

So, and if I got it right, your idea is to delegate the chipset implementation to those FPGA blocks, leaving the CPU to the pure ASIC design, right?
Quote:

cdimauro Quote: No. The clear target for Vampire is assembly programming (and direct hardware hitting). There's no doubt about it, according to the several times that it was repeated by Gunnar or some other Vampire member. For this reason, an assembler (and disassembler) is enough: no high-level compilers support is required. And for the same reason the Vampire will be limited to a niche. Which isn't unexpected, BTW... How useful is an ISA optimized for FPGA cores and assembly programming? Shouldn't ISAs be optimized for ASICs and compilers instead?

Depends on the target market. The Vampire's one is the Amiga fanboys which like to play the software as in the "good old time", and of course it's for the old software.

Do you need an ASIC for that? Do you need compiler support? I don't think so.

Of course, if you have a different market target, then the Vampire design (both ISA and implementation) is not suitable.
Quote:

cdimauro Quote: The thing is very simple: Gunnar likes to decide everything, because the project is essentially his own. He has some ideas about what Vampire should be, and he's pursuing his direction. Is it? Gunnar borrowed Thomas's Natami SAGA and Jen's N68k core. Gunnar provided the determination to keep developing their projects past the point of sanity is all.

OK, it's not all Gunnar's work, but does it matter in this context?

Thomas hasn't delivered. Jens neither. Gunnar has. And the Vampire, as it is, is his project at the very end.
Quote:

cdimauroQuote: And I've nothing to say about it, because I would have done the same if I had his expertise and chance. And you know why? Because, at the very end, he was able to deliver! Deliver a product to people who like exactly what he proposed to them. When I was at Intel I've learned a simple but quite effective mantra which is circulating on the company: deliver is the king! And with this mindset we worked. And delivered. And achieved success. And gained market. Yes, Gunnar delivered something that a few thousand Amiga users like.

Which is great, if you look at how small is the Amiga niche nowadays.

You also have to consider that it (mostly) satisfied the needs of this niche.

Customers satisfaction should be the primary goal for a product. Take a look a the A500 Mini, and you've another example. Others in the retro domain are well known.
Quote:

When Gunnar e-mailed me asking me to join the Apollo Team, he wrote, "all what we wanted to do we reached now". He didn't deliver to me and I don't think I'm alone. Setting low goals is a good way to achievable them.

Sure. And it's easier to arrive to the market as well.

I understand that the Vampire cannot satisfy all its possible audience. And least of all technical people like us. But that's the real life: products in the market aren't suitable for the entire humankind.
Quote:

cdimauro Quote: I think that, as computer architecture passionate people, we recognize mistakes and bad design decisions which Gunnar made with the 68080 (and SAGA too, if we want to extend a bit the topic). But think about it: what could have happened if you were the 68080 designer and you delivered the product according to your vision? Do you think that nobody could have criticized it / your work? That's why asking for input from developers giving them a chance to come up with improvements before making consensus group decisions is a good idea. Data from suggestions should be analyzed of course. It is not possible to please everyone but having ideas rejected by a group majority is reasonable and easier to understand.

This assumes that a commercial product should be "steered" by a community. Which is not the case. The community isn't taking the risk of going to the market.

This model could work if that community consists of stakeholders. Which hasn't happened with the Vampire, right?
Quote:

cdimauro Quote: How many times have we (me, you, megol, Gunnar, etc.) discussed about ISA (and chipset) topics? How many times we had different ideas and disagreed? Countless... Because this is the reality: everyone has HIS vision about how a certain ISA should be designed and implemented. And it's VERY DIFFICULT to find a common agreement. Impossible, I would say, after so much discussions. Gunnar's ISA with all the banks of registers and bolt-ons is not unprecedented. It reminds me of the somewhat 68k like StarCore DSP. https://www.nxp.com/docs/en/reference-manual/MNSC140CORE.pdf It's not general purpose although there are DSPs which are more difficult to program and write a compiler for (it is difficult for a compiler to take advantage of many of the features as with the Apollo ISA).

I know the StarCore, and I agree. But that's a for a different market: DSPs are known to be difficult to take advantage of using regular high-level languages, and you need either intrinsics from compilers, or carefully written assembly code.

Those are different beasts compared to what we usually study / work on / use.
Quote:

Compiler support has to be one of the primary goals.

Again, it strictly depends on the target market.

But I fully agree with you that it's a basic requirement for a general-purpose ISA, which has a broader audience / usage.

Which is not the case for the Vampire, unfortunately.
Quote:

My primary goals for a 64 bit ISA would probably be something like the following. 1. easy to use by compilers 2. similar to existing 68k code with similar ease of use 3. best code density for a general purpose 64 bit ISA

I agree and these (but x86/x64 was also a strong reference for real cases) has driven my decisions for the design of my ISA (which, of course, is general-purpose).
Quote:

Gunnar's ISA goals would be something like the following. 1. optimize for FPGA performance 2. add as many registers as possible and bolt on anything needed wherever it fits 3. easy to use by assembler programmers Gunnar talked like my priorities were important too but then prioritized his own.

Correct. However for point 2 I think that his decision came by designing the AMMX extension, and maybe he simply realized that adding more registers was easy and didn't took much space / effort on the FPGA. Similar decision might have brought to the SMP / Hyperthreading addition to the core.

To me Gunnar's logic is simple: if something is easy to be added to the FPGA, he does it.
Quote:

cdimauro Quote: At least Gunnar was able to deliver. Kudos to him! For this reason I think that we should separate the two things, and don't mix them. One thing is our evaluation about ISA, chipset, and whatever technical topic. Another thing is the products on the market. To be more clear, finger pointing Gunnar for what he did doesn't make sense: those are pointless complaints (here I also see a little bit of envy, eh! I also envy him because he produced something which I wasn't able to do). So, let's limit our analysis to the technologies which were delivered and/or about how personal vision of how things should be done. I don't envy Gunnar. I am more objective about it. He sabotages his own project which the team, including him, worked so hard at.

Well, how can it be a problem for Gunnar if he's still steering the project as he likes? I don't know if it's correct to talk about sabotage, but at the very end the project goes as he wants.

Let's talk frankly: wouldn't you liked to have Gunnar implementing your 64-bit 68K ISA? I mean: exactly like you wanted?

I've no problem telling you that I would really like to have Gunnar, or any other HDL expert at his level, to implement my ISA. Because I know that if there's no concrete implementation that allows to show its strengths then there's simply no chance to at least reach the mass market. Otherwise they remains just unrealized dreams.

It's the American dream... and this is your dream, from what I've read from you since years now.

But you should understand that finger-pointing Gunnar for that missed opportunity brings you to nowhere. Past is past, and the things with Gunnar are unlikely to change. Try to find some other solution, and be in peace with yourself...
Quote:

I feel sorry for him but not as sorry as I feel for Jens and Thomas who did everything right except let Gunnar be in charge. I do have a good reason to talk about it because I was part of it.

OK, but who stops Jens and Thomas to continue with their projects? Or maybe someone to take their projects, combine them, and continue the work in a direction similar to what you like?

I mean: the HDL code for Natami chipset and for the 68050 is still available, right? And if you take a look at the Amiga FPGA products then you realize that they aren't even able to outperform the best Commodore machines

So, if improvements are welcome AND really needed / demanded by the market (AKA customers) then why don't you take Thomas' and Jens' work and create a better product?

@amigang @all

I again would like to describe how I see the situation. We have the concepts of our traditional amigaos. All so called NG platforms inherited most of the limitations (32bit with exception of AROS, no mlutiprocessor support, no memory protection) because 68k binaries should work with it. But when amigaos was designed situation was very different. Now f.e. security is much more important than it was at that time. So all amiga platforms are (in current terms) very old houses with old infrastructure and need a lot of changes to become modern.

There are basically two branches... the 68k branch including all sort of amigaos versions and aros 68k, on the other hand "NG" what is far from being useable in todays terms.

I like 68k very much, it is retro and a fun platform, but nevertheless it is not modern in todays terms. To make it "modern" you would need to make drastic changes and you would break lots of software and still you would have problems like missing drivers and no modern software. That does not change with virtual platforms or a new amithlon. I think 68k should stay what it is and in my view UAE is enough and Michal is doing emu68 that might end in a amithlon like platform for ARM. Additional there are new platforms like PiStorm and V4 range.

The other idea is to get something useable in todays terms. The problem is it needs a lot of changes and even then you miss driver support and modern software like up-to-date browser. That is a basic problem of any niche operating system and not easy to overcome. There I see AxRuntime from Deadwood as a big chance because it might result in a kind of linux environment (and perhaps Windows) that has look&feel of amiga. I know that this also will not make everyone happy but it is maximum we can get today. You can of course update also AROS, AmigaOS and MorphOS and we will see where this gets. But even after updating (that is lots of work) you still have the typical shortcomings of niche systems.

@cdimauro

Quote:

If you take a look at Karlos' MC64K ISA, for example, you can clearly see that it was designed (I refer to the opcodes structure) to have it easily emulated in software -> create a very efficient VM for it (and likely an efficient JIT). However, and due to the same design decisions, it's difficult to be implemented in hardware (very similar to the VAX ISA issues, from this PoV), and not well suitable for real code due to not good code density (this is my guess looking at opcodes, of course). Pros and cons: that's the real world! A design comes the synthesis of several requirements & constrains.

Correct. The simplicity of interpretation and JIT were main motivators for the format. As was the decision to not explicitly model CCR.

Code density wise, it isn't as bad as you may expect for what you could consider idiomatic 68K style assembler. Most dyadic register to register instructions take 3 bytes, as do register indirect (sans fixed displacement), indirect with increment/decrement. Integer immediate values are encoded in the smallest word size that can represent the value.

The most egregious example, at 20 bytes, would be something like a double precision compare and branch between an immediate value and a scaled register indexed with 32-bit displacement EA.

Most instructions, most of the time are 3-5 bytes. Bad compared to actual 68K, but then again they can do more work than 68K too, with EA for both source and destination operands, so it's not the worst overall tradeoff.

Last edited by Karlos on 08-May-2022 at 10:50 AM.

_________________
Doing stupid things for fun...

@NutsAboutAmiga: thanks!


@Karlos

Quote:

Karlos wrote: @cdimauro Quote: If you take a look at Karlos' MC64K ISA, for example, you can clearly see that it was designed (I refer to the opcodes structure) to have it easily emulated in software -> create a very efficient VM for it (and likely an efficient JIT). However, and due to the same design decisions, it's difficult to be implemented in hardware (very similar to the VAX ISA issues, from this PoV), and not well suitable for real code due to not good code density (this is my guess looking at opcodes, of course). Pros and cons: that's the real world! A design comes the synthesis of several requirements & constrains. Correct. The simplicity of interpretation and JIT were main motivators for the format. As was the decision to not explicitly model CCR. Code density wise, it isn't as bad for what you might consider idiomatic 68K style assembler. Most dyadic register to register instructions take 3 bytes, as do register indirect (sans fixed displacement), indirect with increment/decrement.

That's better than what I was able to achieve with my ISA, which requires 4 bytes in those cases. However I had a large amount of instructions to be encoded (full x86/x64 set: 8 bits for the base opcode wasn't enough).
Quote:

Integer immediate values are encoded in the smallest word size that can represent the value.

Nice. Very similar to my design. This is one point where 68K needs improvements.
Quote:

The most egregious example, at 20 bytes, would be something like a double precision compare and branch between an immediate value and a scaled register indexed with 32-bit displacement EA.

Large instructions... like 68K.

My largest is 22 bytes, for a 64-bit integer immediate + 32-bit memory displacement + EA + base opcode + opcode extender.

However I decided to follow the x86/x64 way, and don't support compare & branch for floating point instructions. Those are much rarely used on real code: FP code isn't branch-intensive, and modern ISAs have SIMD/vector extensions with predication: I adopted the same model.
Quote:

Most instructions, most of the time are 3-5 bytes. Bad compared to actual 68K,

Indeed. Doesn't look good: 68K is very known to have a very good code density.

Have you tried to get some statistics (see below)?
Quote:

but then again they can do more work than 68K too, with EA for both source and destination operands, so it's not the worst overall tradeoff.

That's also very similar to my ISA. However the problem with "richer" (let's say this) instructions / opcodes is that they need to be used. And measured.

I've written a Python script to get some statics about my ISA, by disassembling x86/x64 binaries (my ISA was born more to replace x86/x64 than 68K, albeit I've borrowed some 68K concepts) and re-encoding them with my instructions.
I've also implemented a peepholer trying to catch some pattern and use some advanced features of my ISA (triadic instructions, dual EA, 64-bit immediates, etc.).

The results are good (better than x86, and way better than x64), but sub-optimal (the ISA can do much better). A backend for a mainstream compiler is definitely needed.

@cdimauro

Quote:

OS4 is on a so bad shape that A-EON is trying to rewrite parts of it (or even all, due to the situation).

A-EON is rewriting parts of OS4 not because the system is "in a bad shape" but because of the stalemate that arose from the Hyperion/Cloanto lawsuit. For several years A-EON have been working on a new OS4 graphics subsystem (both 2D and 3D), which is now approaching a state that it cannot be simply added to the OS but needs adaptation of the graphics subsystem libraries. With Hyperion being totally unpredictable, A-EON decided they no longer wanted to be dependent on Ben Hermans' momentary whim, and started developing their own distribution. Whether their effort ultimately turns into an OS4 replacement, whether it is a good idea at all, and whether yet another NG system stands a realistic chance of user adoption will remain to be seen.

_________________
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

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. The goal was just to provide an assembler experience close to what we remembered, without some of the limitations we preferred to forget. The compare and branch models how you tend to write code in higher level languages, i.e. "if (a > b) ..."

It's not intended as a VM for general use, it's more for nostagic purposes. 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

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)

Last edited by Karlos on 08-May-2022 at 12:48 PM.
Last edited by Karlos on 08-May-2022 at 12:41 PM.
Last edited by Karlos on 08-May-2022 at 12:41 PM.

_________________
Doing stupid things for fun...

@Trixie

Quote:

A-EON is rewriting parts of OS4 not JUST because the system is "in a bad shape" but ALSO because of the stalemate that arose from the H̶y̶p̶e̶r̶i̶o̶n̶/̶C̶l̶o̶a̶n̶t̶o̶ Thieves/Kiddies lawsuit

THERE, FRIEND TRIXIE, FIXED IT FOR YOU.

NO CHARGE THIS TIME.



/mega!

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

@Nonefornow

Quote:

Maybe it is time for all those conflicting parties to drop their esoteric projects and initiatives and pool their resources to advance AROS development.

Who Hyperion and Cloanto? And others? They aren't going to drop the actual AmigaOS code or what's left of it for a copy.

@cdimauro

Quote:

OS4 is on a so bad shape that A-EON is trying to rewrite parts of it (or even all, due to the situation).

They need to write it from scratch. They can't rewrite it without the source. OS4 would have been better off if old bugs were fixed before new features added. I can learn from my own experience with home coding. Adding heaps of features but finding bugs need to be fixed before new features go on or the bugs will grow and escalate.

In any case rewriting it will not fix it. It will just copy it. And copies problems which also can have copying mistakes. And in this case doesn't fix the hardware problem. So it will be copied onto the same hardware.

It may be like an Apple upgrade routine. Where the last major OS version has bugs. Then you need to purchase the next version to have the old bugs fixed. Simple business practice. I found some bugs in Enhancer components I had, that had been updated since, but I couldn't download them because I needed to buy the next version first.

@Hypex

Even if, what is the market for OS4 exactly? It is neither modern enough nor retro like 68k?

@NutsAboutAmiga

Quote:

There absolute difference in how AmigaOS4.x behaves vs AmigaOS3.x, for example AmigaOS4.x default to true color chunky modes, if no mode id is set in OpenScreenTags, that one is problematic, as a lot programs, and games are hard coded, to 40 bytes per row, planar screens as default, AmigaOS4.x uses 80 bytes per row (640 pixel on lowres), stuff like that does not make things easier.

Yeah the wrong screen size is annoying. It was fine on the XE where you could have proper low res modes even though the P96 defaults were all wrong at hires and had to be setup manually. But for a long time now 640 is a minimum supported in hardware. So it can't be done directly any more, it must be scaled either way. So need some kind of hardware emulation. The copper trick would have been done like this. Using some kind of blitter to simulate the sliding screen trick. Unless they did raster interrupts.

Quote:

Raw key codes, is also problematic, Amiga keyboard and AmigaOS4.1 usb keyboards, do not use the same key codes. That’s problematic, when your running old 68k program. it be good ide if input.device know if the program is 68K program or PPC program, maybe Exchange app can fix it, yet it is a problem.

That shouldn't be an issue. Though raw keys related direct to an Amiga keyboard they are also an Amiga standard so should be translated from other hardware. The CD32 could be used with PS/2 keyboards and those used different key codes. So it shouldn't matter. I don't recall any problems myself. Where does it differ in codes?

@OlafS25

The market is those who are OS4 users already. Who like a continuation of AmigaOS on newer hardware. Of course this goes back 20 years really. The point is still the same. But the divide has increased widely in OS and hardware standards since the last 20 years so it's harder to see it.

@Hypex

Quote:

It may be like an Apple upgrade routine.

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

The concept of "Doing it right the first time" does not exist anymore. (Or at least in software development at Apple)

So Apple has embraced the upgrade process as part of its secular evangelism. They do not even try to get a final product.

Last edited by Nonefornow on 08-May-2022 at 06:04 PM.

@Nonefornow

Quote:

So Apple has embraced the upgrade process as part of its secular evangelism. They do not even try to get a final product.

As opposed to?

_________________
All the way, with 68k

@agami

Quote:

As opposed to?

Don't be crappy.

@Trixie

Quote:

Trixie wrote: @cdimauro Quote: OS4 is on a so bad shape that A-EON is trying to rewrite parts of it (or even all, due to the situation). A-EON is rewriting parts of OS4 not because the system is "in a bad shape" but because of the stalemate that arose from the Hyperion/Cloanto lawsuit.

That's simply not true.

In fact, nobody stopped Hyperion to realize and sell Amiga OS 3.1.4 first, and then OS 3.2. Which are clearly on Cloanto's domain...

And who stopped Hyperion to continue focusing on OS4, which at least is ITS product (not in the Cloanto's domain)?

BTW, if Cloanto wins the lawsuit against Hyperion, then I suggest Michele Battilana to sue OS 3.1.4/3.2 developers, because they clearly worked on those products without the rights to do it.
Especially for 3.2, they cannot say "we didn't know of the lawsuit, and the issues with the Amiga o.s. rights".
With their work they contributed / financed Hyperion for the lawsuit. So, they are effectively Ben's accessories...
Quote:

For several years A-EON have been working on a new OS4 graphics subsystem (both 2D and 3D), which is now approaching a state that it cannot be simply added to the OS but needs adaptation of the graphics subsystem libraries. With Hyperion being totally unpredictable, A-EON decided they no longer wanted to be dependent on Ben Hermans' momentary whim, and started developing their own distribution. Whether their effort ultimately turns into an OS4 replacement, whether it is a good idea at all, and whether yet another NG system stands a realistic chance of user adoption will remain to be seen.

Changes at the graphic subsystem require to completely rewrite common command lines applications? Even very simple ones?

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: OS4 is on a so bad shape that A-EON is trying to rewrite parts of it (or even all, due to the situation). They need to write it from scratch. They can't rewrite it without the source. OS4 would have been better off if old bugs were fixed before new features added. I can learn from my own experience with home coding. Adding heaps of features but finding bugs need to be fixed before new features go on or the bugs will grow and escalate. In any case rewriting it will not fix it. It will just copy it. And copies problems which also can have copying mistakes. And in this case doesn't fix the hardware problem. So it will be copied onto the same hardware. It may be like an Apple upgrade routine. Where the last major OS version has bugs. Then you need to purchase the next version to have the old bugs fixed. Simple business practice. I found some bugs in Enhancer components I had, that had been updated since, but I couldn't download them because I needed to buy the next version first.

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.

Besides that, see my reply to Trixie.