@cdimauro
Quote:

cdimauro wrote: @Karlos Sort of. At least it's what I expect from for modern languages. Quote: I haven't implemented one but I had intended that exvm and MC64K should be AOT recompilable, though the latter may be trickier as it's more open to abuse (just like the real thing, I guess). Well, exvm and MC64K are architectures, so JITs for them should be totally transparent. What helps a JIT/AOT compiler, in general, is the metadata that you embedded on the binaries generated. For example entry points for functions (with prologue/epilogue) and lines or even (this is especially useful) instructions debug info. This helps understanding how the code / instructions workflow is made / connected, and generate better code (or generate the entire code if the goal is AOT).

Definitely. But there are some important architectural differences between these two VM designs. In exvm, function calls are either pure PC relative for closed / static scoped functions (same translation unit) or via a 20-bit ID value that is a lookup into a runtime resolved vector of addresses. A host native call works the same way, but has a separate opcode to identify it as a native call and a separate vector of addresses.

This means that no exvm code can refer to more than ~1M enumerated VM functions and no more than ~1M host exported native entry points. In practise this doesn't seem like a particularly bad restriction. The important trade off is that the opcode stream never contains real code addresses and even if you want to make an indirect call, it's still the enumerated ID that you have to have in the register. As a result, every place that the VM can begin execution from is knowable AOT, and therefore in theory, translatable AOT. At least that was my thinking.

In contrast, MC64K in addition to PC relative calls, has jmp and jsr opcodes, that like a real 68K, can take any pattern of bits as an address and branch there. As the repository readme makes clear, there's no safety ;)

Quote:

The problem comes with pure binaries (like 68K JITs for our Amiga), where usually you have no metadata and you need to build it at runtime...

I definitely think additional sections in the EHF format could help with that, especially with improved compiler / assembler support.

Quote:

Quote: My knowledge of x64 assembler is not up to the task yet, but it's an excuse to learn. It's quite simple for people coming from 68K: it's a CISC, with some similarities (stack pointer as regular reg, base / indexed memory modes, mem instructions). You need to get used to the slightly different syntax, but this you'll do quickly.

I'd rather target x64 directly as I have bad memories of x86. However, there's just so much stuff to know to leverage x64 well. Maybe I'm getting too old for it

_________________
Doing stupid things for fun...

This conversation is giving me the itch to update exvm lol.

_________________
Doing stupid things for fun...

@Karlos and all!

I always wondered why we call WinUAE (or other UAE) an Emulator rather than a Virtual Machine?

Cheers!

_________________
Tygre
Scientific Progress Goes Boing!

@tygre

It's a good question. My personal opinion is that Emulators form a distinct subset of Virtual Machines. That is to say, they replicate the behaviour of some existing (usually physical hardware) system. The term Virtual Machine also covers examples of machines that are not emulators and are just pure software state machine / interpreters. For example, the runtime for many languages like Java, JavaScript, PHP, Python, etc.

_________________
Doing stupid things for fun...

I agree.

@Karlos

Quote:

Karlos wrote: But there are some important architectural differences between these two VM designs. In exvm, function calls are either pure PC relative for closed / static scoped functions (same translation unit) or via a 20-bit ID value that is a lookup into a runtime resolved vector of addresses. A host native call works the same way, but has a separate opcode to identify it as a native call and a separate vector of addresses. This means that no exvm code can refer to more than ~1M enumerated VM functions and no more than ~1M host exported native entry points. In practise this doesn't seem like a particularly bad restriction. The important trade off is that the opcode stream never contains real code addresses and even if you want to make an indirect call, it's still the enumerated ID that you have to have in the register. As a result, every place that the VM can begin execution from is knowable AOT, and therefore in theory, translatable AOT. At least that was my thinking.

It should work out if you have no indirect calls/jumps (e.g.: function pointers).
Quote:

cdimauro wrote: Quote: The problem comes with pure binaries (like 68K JITs for our Amiga), where usually you have no metadata and you need to build it at runtime... I definitely think additional sections in the EHF format could help with that, especially with improved compiler / assembler support.

EHF == ELF?

I think that the DWARF debug section should be enough for that.
Quote:

Quote: It's quite simple for people coming from 68K: it's a CISC, with some similarities (stack pointer as regular reg, base / indexed memory modes, mem instructions). You need to get used to the slightly different syntax, but this you'll do quickly. I'd rather target x64 directly as I have bad memories of x86. However, there's just so much stuff to know to leverage x64 well. Maybe I'm getting too old for it

Sure, x86 is legacy: there are no 32-bit only PCs sold already since some years, and most os.es dropped x86 support already.

So, x64 is the only ISA to consider.
@Karlos

Quote:

Karlos wrote: This conversation is giving me the itch to update exvm lol.

Good. You can make it more general-purpose & complete.

And you can better use the opcode space to make instructions more compact or open new "slots" for more instructions.

@cdimauro

I meant the hunk format used by classic AmigaOS, extended to include the metadata. Then I remembered after posting that extended hunk format already existed. It's what WarpOS used, IIRC. Obviously, OS4 and other evolutions support ELF directly, but I'm thinking about what the lowest common denominator is for system friendly AmigaOS 68K executables. I'm still dreaming of a 68k based CLR you see ;)

_________________
Doing stupid things for fun...

-- duplicate post --

Last edited by Karlos on 14-May-2022 at 12:05 AM.

_________________
Doing stupid things for fun...

Karlos Quote:

I meant the hunk format used by classic AmigaOS, extended to include the metadata. Then I remembered after posting that extended hunk format already existed. It's what WarpOS used, IIRC. Obviously, OS4 and other evolutions support ELF directly, but I'm thinking about what the lowest common denominator is for system friendly AmigaOS 68K executables. I'm still dreaming of a 68k based CLR you see ;)

As I recall, custom debug hunks could contain metadata, profiling data, etc. These hunks are ignored on native execution but could be read by an emulator. Compiling with symbol and debug hunks could aid emulation. The intelligent disassembler ADis, which I enhanced, uses symbol hunk data to learn function entry points in code and data offsets and sizes in data and bss hunks. The disassembled output reflects data flags which are altered based on various sources including symbol hunk data.

Emulation and late compilation is still very inefficient. It can be tuned for a particular application.

interpreted emulator - tuned for low memory
AOT compiler - tuned for fast startup
JIT compiler/emulator - tuned for performance

Real hardware is good in all three categories instead of one. Adding more metadata or profiling data will likely improve performance while slowing startup and increasing memory usage. Emulating the 68k CPU is fast because Amiga programs are small commonly being written in C and assembler which is still the best for performance and size (low memory and fast startup) today. That old school efficiency is dead today and replaced with OOP bloat and now emulation bloat. Who cares if a program uses 1GiB instead of 1MiB of memory though? Aren't memory and chip transistors cheap? Isn't the Amiga philosophy dead but then why emulate it?

@matthey

Quote:

matthey wrote: Emulation and late compilation is still very inefficient. It can be tuned for a particular application. interpreted emulator - tuned for low memory AOT compiler - tuned for fast startup JIT compiler/emulator - tuned for performance

That's not correct: AOT compilation offers fast startup, low memory usage, and high performance.

The goal for AOT is having a binary generated for the host architecture/platform, coming from the full compilation of the guest/original one.

Once you have the new binary you can forget the original one (in theory the original code could be fully removed and replaced by the new/host one, leaving only the data structures).

So, the new binary is like a native application, with all the benefits that comes from it.
Quote:

Real hardware is good in all three categories instead of one.

Only if you have it running at decent speeds.
Quote:

Adding more metadata or profiling data will likely improve performance while slowing startup and increasing memory usage.

See above: not for AOT.
Quote:

Emulating the 68k CPU is fast because Amiga programs are small commonly being written in C and assembler which is still the best for performance and size (low memory and fast startup) today. That old school efficiency is dead today and replaced with OOP bloat

In fact the old school is dead for good reasons, which I've already explained on the other thread, and you look like a cavemen finger pointing OOP and calling it as "bloat".

Maybe you forgot the OOP implementation which was introduced by Commodore engineers on Amiga o.s.: this is the real case where you can use "bloat". Please, tell me how efficient is it compared to the classic VMT.

And the same happens with the tagslists: a complete bloat, compared to the classic "structure" (struct in C).
Quote:

and now emulation bloat.

Why aren't you honest? Emulation is bloat simply because you don't like it. Because you see it has a threat to a native 68K implementation (in ASIC).

Is Michal's Emu68 bloat? Have you seen what he was able to achieve from a low cost, low power, and low performance Raspberry Pi? Is around 1/3 of the native ARM performances "bloat" in your opinion?
Quote:

Who cares if a program uses 1GiB instead of 1MiB of memory though?

Come on, this is just a slogan, and you know it. What's the context? You forgot it.

Please, let me how to get a modern AND fast browser with your good, old school, and which uses 1MB of memory instead of 1GB.

I'm can't wait to know how you would do it...
Quote:

Aren't memory and chip transistors cheap?

Quote:

Isn't the Amiga philosophy dead but then why emulate it?

That's a simple logical fallacy, Matt. The fact that the Amiga philosophy (which to me also means: do whatever you want. You know why the Amiga o.s. is so fragile, unsecure, and wasn't possible to enhance it: it's because of this old school mindset) is dead does NOT imply that it shouldn't be emulated. This is elementary logic.

Emulating Amigas has nothing different from emulating C64s, Spectrums, etc., or even a complete Playstation 3 (which I can emulate full speed with my new Alder Lake 12900K with AVX-512 enabled. Try to do the same with a 5Ghz 68K ASIC...).

Tell me why it should be different for the Amiga, which is a retroplatform like all the above.

@matthey

Quote:

Emulation and late compilation is still very inefficient. It can be tuned for a particular application. interpreted emulator - tuned for low memory AOT compiler - tuned for fast startup JIT compiler/emulator - tuned for performance Real hardware is good in all three categories instead of one. Adding more metadata or profiling data will likely improve performance while slowing startup and increasing memory usage. Emulating the 68k CPU is fast because Amiga programs are small commonly being written in C and assembler which is still the best for performance and size (low memory and fast startup) today. That old school efficiency is dead today and replaced with OOP bloat and now emulation bloat. Who cares if a program uses 1GiB instead of 1MiB of memory though? Aren't memory and chip transistors cheap? Isn't the Amiga philosophy dead but then why emulate it?

There's a lot wrong here. AOT means ahead of time. As in, during installation. You never pay any runtime costs for translation. However, the same original binary can still be executed in a JIT, interpreter or real silicon. Which is the whole point.

Emulating 68K is fast, because emulating 68K is fast. It's a well documented, well understood architecture with multiple mature emulations available. Amiga application size, complexity or approach has nothing to do with it. Your fast modern 68K emulation will run just about any 68K code faster than currently available silicon does, regardless of what platform is being run on it.

As for OO bloat. What does that have to do with anything here? OO is a paradigm and like every paradigm it has places where it gives proven benefits. Let's not forget that OO code is also procedural (that is, methods are functions). It just allows you to make abstractions around them and how they are associated with the structures they operate on that are useful in complexity management.

As pointed out above, BOOPSI was OO and from that we got flexible user interfaces and datatypes. And these were implemented in an extraordinarily clunky way compared to how a language like C++ implements a virtual function call. Which was also a trade off. You got to write code in C and you got to define and extend types and behaviours at runtime.

Last edited by Karlos on 14-May-2022 at 10:16 AM.
Last edited by Karlos on 14-May-2022 at 09:59 AM.

_________________
Doing stupid things for fun...

cdimauro Quote:

That's not correct: AOT compilation offers fast startup, low memory usage, and high performance. The goal for AOT is having a binary generated for the host architecture/platform, coming from the full compilation of the guest/original one. Once you have the new binary you can forget the original one (in theory the original code could be fully removed and replaced by the new/host one, leaving only the data structures). So, the new binary is like a native application, with all the benefits that comes from it.

AOT compilation is usually used where standard hardware is severely lacking. Good examples would be to support the many smart phone architectures or to support the many GPU architectures with shader code. AOT runtime performance is no better than pre-compiled binaries from developers and can be worse as the developers may have time to fine tune the compilation settings, compile at higher optimization levels, profile the code, etc. AOT runtime performance is usually worse than pre-compiled binaries for standard hardware. Compilation often requires a modern compiler based on LLVM which can use quite a bit of memory though runtime memory usage is decreased to similar to a native binary. Fast startup is usually the goal of AOT compilation as the self profiling nature of JIT has more performance potential after a warmup period and at the cost of using more runtime memory.

It would be possible to use AOT recompilation (or disassembly conversion and reassembly) to convert from one binary format to another. For example, 68k code could be converted to x86-64 code. Runtime performance is likely to be lost as compared to compiling from sources which takes advantage of the target hardware. Disassembling the original binary is error prone. This does not sound like a good idea to me.

cdimauro Quote:

See above: not for AOT.

Metadata and profiling data should improve runtime performance of AOT compiles like I said. The data could disappear from the AOT generated binary so it would not affect startup time and increase memory requirements. AOT compilation time and memory usage may increase though.

cdimauro Quote:

In fact the old school is dead for good reasons, which I've already explained on the other thread, and you look like a cavemen finger pointing OOP and calling it as "bloat". Maybe you forgot the OOP implementation which was introduced by Commodore engineers on Amiga o.s.: this is the real case where you can use "bloat". Please, tell me how efficient is it compared to the classic VMT. And the same happens with the tagslists: a complete bloat, compared to the classic "structure" (struct in C).

The original Amiga use of structures is more efficient for performance and memory usage than taglists. BOOPSI is far from efficient for performance but the memory efficiency is not bad due to code sharing. Indirect branches are minimized which shows the developers knew what was inefficient which is more than I can say for most modern object oriented code.

cdimauro Quote:

Why aren't you honest? Emulation is bloat simply because you don't like it. Because you see it has a threat to a native 68K implementation (in ASIC). Is Michal's Emu68 bloat? Have you seen what he was able to achieve from a low cost, low power, and low performance Raspberry Pi? Is around 1/3 of the native ARM performances "bloat" in your opinion?

Emulation is bloat because it is wasteful and unnecessary, especially for a primary system environment or virtual machine. 1/3 of native performance is poor but that is not all. There is increased memory usage, slower startup times, increased latency and increased jitter.

cdimauro Quote:

That's a simple logical fallacy, Matt. The fact that the Amiga philosophy (which to me also means: do whatever you want. You know why the Amiga o.s. is so fragile, unsecure, and wasn't possible to enhance it: it's because of this old school mindset) is dead does NOT imply that it shouldn't be emulated. This is elementary logic. Emulating Amigas has nothing different from emulating C64s, Spectrums, etc., or even a complete Playstation 3 (which I can emulate full speed with my new Alder Lake 12900K with AVX-512 enabled. Try to do the same with a 5Ghz 68K ASIC...). Tell me why it should be different for the Amiga, which is a retroplatform like all the above.

The AmigaOS would run on a 5GHz 68k ASIC and most of the software would run. With it, there would likely be more memory than practically any old Amiga yet the memory could be utilized. This is not true of a C64, Spectrum, Playstation 3 or even Archimedes with ARM 26 bit addressing. Why do I need a $589 CPU which draws 125W when a $5 SoC ASIC drawing 5W would suffice? Why does THEA500 need a 1-2GHz CPU with 256MiB of memory to emulate an Amiga 500 with 7MHz 68000 and 1MiB of memory? Why is the Raspberry Pi a better old school philosophical successor to the Amiga than anything Amiga in decades?

Last edited by matthey on 15-May-2022 at 01:12 AM.
Last edited by matthey on 15-May-2022 at 01:10 AM.
Last edited by matthey on 15-May-2022 at 01:08 AM.

Quote:

Why do I need a $589 CPU which draws 125W when a $5 SoC ASIC drawing 5W would suffice? Why does THEA500 need a 1-2GHz CPU with 256MiB of memory to emulate an Amiga 500 with 7MHz 68000 and 1MiB of memory? Why is the Raspberry Pi a better old school philosophical successor to the Amiga than anything Amiga in decades?

But!
Most Importantly!

Why should anyone think that a pluri-banned peddler of wheels who runs a year-1995 html-0.9 website and can't even get basic spelling right on the very first section of the homepage - would be a savvy source of knowledge on SOCs, emulation, instructions and architectures?

; -))) ;- P :oD

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

@matthey

There is no 5GHz ASIC for running 68K code and there likely never will be. It's an absolute fantasy and no matter how warm and fuzzy the idea makes you feel, it's not anything that can be used. What do we actually have, today, to actually work with? Real 68K hardware, FPGA reimplementation. Beyond those, there are performant JIT emulation. These are the tools to leverage because they are real, proven technology.

In a CLR model, AOT recompilation to native code would be a target for new software, having certain sensible guarantees (not self modifying, all entry points known, etc ) and JIT as a fallback for anything not meeting those requirements, i.e. all existing software.

_________________
Doing stupid things for fun...

MEGA_RJ_MICAL Quote:

Why should anyone think that a pluri-banned peddler of wheels who runs a year-1995 html-0.9 website and can't even get basic spelling right on the very first section of the homepage - would be a savvy source of knowledge on SOCs, emulation, instructions and architectures?

I am not the webmaster of the website anymore although I did most of the work on it including designing the logo, mostly done on the Amiga. Yes, the HTML standard I used was the minimal necessary. It worked on old browsers from the '90s and modern smart phones while the minimal page sizes gave fast loading times. No pop ups, no cookies. Less was more without the bloat. The website was not my main responsibility. I primarily made steel wheels for agriculture use.

Karlos Quote:

There is no 5GHz ASIC for running 68K code and there likely never will be. It's an absolute fantasy and no matter how warm and fuzzy the idea makes you feel, it's not anything that can be used. What do we actually have, today, to actually work with? Real 68K hardware, FPGA reimplementation. Beyond those, there are performant JIT emulation. These are the tools to leverage because they are real, proven technology. In a CLR model, AOT recompilation to native code would be a target for new software, having certain sensible guarantees (not self modifying, all entry points known, etc ) and JIT as a fallback for anything not meeting those requirements, i.e. all existing software.

A 5GHz 68k ASIC is unrealistic but a 1-2GHz ASIC is realistic with cooperation. I understand that JIT is a proven technology even though it is complex and error prone as can be seen by problems with UAE JIT despite being out for so long. There is a reason why JIT is left off for better compatibility on THEA500 Mini and why Toni Wilen doesn't bother with bug reports while JIT is on. Sorry, AOT compilation for new software for an Amiga like virtual machine is cringe worthy. Just compile for a bastard Amiga like system if you don't value compatibility or use JIT for the standard 68k Amiga "virtual machine" if you value better compatibility. There is a reason why UAE is more popular than AmigaOS 4, MorphOS and AROS flavors. That is all we can hope for without new affordable 68k Amiga hardware.

@matthey

Quote:

matthey wrote: cdimauro Quote: That's not correct: AOT compilation offers fast startup, low memory usage, and high performance. The goal for AOT is having a binary generated for the host architecture/platform, coming from the full compilation of the guest/original one. Once you have the new binary you can forget the original one (in theory the original code could be fully removed and replaced by the new/host one, leaving only the data structures). So, the new binary is like a native application, with all the benefits that comes from it. AOT compilation is usually used where standard hardware is severely lacking. Good examples would be to support the many smart phone architectures or to support the many GPU architectures with shader code.

In understand the point, but AOT was/is wide-spread on standard hardware. Notable examples: .NET was born on PCs/x86, and Dalvik on Android/ARM (32-bit).
Quote:

AOT runtime performance is no better than pre-compiled binaries from developers and can be worse as the developers may have time to fine tune the compilation settings, compile at higher optimization levels, profile the code, etc. AOT runtime performance is usually worse than pre-compiled binaries for standard hardware.

OK, but nobody claimed that AOT should have had the same or even better performances of native binaries which are carefully compiled by developers. What's important is that AOT gives good performances (also very good) for what's needed / wanted by customers.
Quote:

Compilation often requires a modern compiler based on LLVM which can use quite a bit of memory though runtime memory usage is decreased to similar to a native binary.

This isn't important as long as it's only on the compilation phase. You don't need it, once you have the binary from the AOT compilation.
Quote:

Fast startup is usually the goal of AOT compilation as the self profiling nature of JIT has more performance potential after a warmup period and at the cost of using more runtime memory. It would be possible to use AOT recompilation (or disassembly conversion and reassembly) to convert from one binary format to another. For example, 68k code could be converted to x86-64 code. Runtime performance is likely to be lost as compared to compiling from sources which takes advantage of the target hardware. Disassembling the original binary is error prone. This does not sound like a good idea to me.

Well, the goal is to have a good compromise, like all things.

My idea of AOT for 68k code is to collect as much as information possible using a plain emulator and attach it as metadata to blocks of 68K instructions or even to single instructions. Once you have covered (almost) all code and collected enough data, then you can use an AOT compiler and generate a native binary which should get good performances, at least comparable to a JIT. And I think even better, because with an AOT compiler you've the chance to also do static analysis of execution workflows and much better optimize the native code.

This is essentially the idea that I carry from several years, and that I call as "virtualizer".

Of course, you can generate better native code if you've the original sources, but I think that the above should give good and likely comparable outcomes.
Quote:

cdimauro Quote: See above: not for AOT. Metadata and profiling data should improve runtime performance of AOT compiles like I said. The data could disappear from the AOT generated binary so it would not affect startup time and increase memory requirements. AOT compilation time and memory usage may increase though.

Correct, but see the above: there's a way to get better results without increasing memory usage.
Quote:

cdimauro Quote: In fact the old school is dead for good reasons, which I've already explained on the other thread, and you look like a cavemen finger pointing OOP and calling it as "bloat". Maybe you forgot the OOP implementation which was introduced by Commodore engineers on Amiga o.s.: this is the real case where you can use "bloat". Please, tell me how efficient is it compared to the classic VMT. And the same happens with the tagslists: a complete bloat, compared to the classic "structure" (struct in C). The original Amiga use of structures is more efficient for performance and memory usage than taglists. BOOPSI is far from efficient for performance but the memory efficiency is not bad due to code sharing.

Code sharing is the base idea on software, which is exploited with OOP. So, no news here.
Quote:

Indirect branches are minimized which shows the developers knew what was inefficient which is more than I can say for most modern object oriented code.

Do you really prefer the chains of compare-and-jump of BOOPSI to the VMTs (so, indirect branches) of modern (well, non that modern in reality: I first saw it implemented on Turbo Pascal 5) OOP platforms?
Quote:

cdimauro Quote: Why aren't you honest? Emulation is bloat simply because you don't like it. Because you see it has a threat to a native 68K implementation (in ASIC). Is Michal's Emu68 bloat? Have you seen what he was able to achieve from a low cost, low power, and low performance Raspberry Pi? Is around 1/3 of the native ARM performances "bloat" in your opinion? Emulation is bloat because it is wasteful and unnecessary, especially for a primary system environment or virtual machine. 1/3 of native performance is poor but that is not all.

It's obviously wasteful compared to the original platform, but numbers aren't bad, and 1/3 of native performance is a great achievement IMO.
Quote:

There is increased memory usage, slower startup times, increased latency and increased jitter.

Right, but you've to take a look at the results. If they are acceptable, or even good, then... why not?
Quote:

cdimauro Quote: That's a simple logical fallacy, Matt. The fact that the Amiga philosophy (which to me also means: do whatever you want. You know why the Amiga o.s. is so fragile, unsecure, and wasn't possible to enhance it: it's because of this old school mindset) is dead does NOT imply that it shouldn't be emulated. This is elementary logic. Emulating Amigas has nothing different from emulating C64s, Spectrums, etc., or even a complete Playstation 3 (which I can emulate full speed with my new Alder Lake 12900K with AVX-512 enabled. Try to do the same with a 5Ghz 68K ASIC...). Tell me why it should be different for the Amiga, which is a retroplatform like all the above. The AmigaOS would run on a 5GHz 68k ASIC and most of the software would run.

Which software, Matt? Do you think that the Amiga software is so important to justify the need of a 68k ASIC? And needs to run at 5Ghz?

The Amiga software is retro like the hardware...
Quote:

With it, there would likely be more memory than practically any old Amiga yet the memory could be utilized.

Which is 2GB maximum and total: not even the cheapest graphic card have this amount of memory nowadays.

Where do you want to go with a system which has a total of 2GB of address space for everything?
Quote:

This is not true of a C64, Spectrum, Playstation 3 or even Archimedes with ARM 26 bit addressing.

Not really right for the C64, because it can be expanded and a better CPUs can also be mounted.

However the concept is clear: they are retro platforms, and expansion usually is not possible.
Quote:

Why do I need a $589 CPU which draws 125W when a $5 SoC ASIC drawing 5W would suffice?

Because, as I've said, I can emulate a PS3 at full speed... and with much better graphic!

This is one of the reasons why emulation is much better than compared to a native platform: you can enhance the original platform and/or the software.
For example replacing the graphic assets with 32-bit and high resolution graphic. Or the audio samples with 16/24 bit ones. Panning the audio channels on both left and right. Or allowing to play both music and SFXs (this requires small changes to the original code, anyway). Etc. etc.

This is also a domain of the above virtualizer: by tracing the 68k code execution it can map all used resources at any time, export them, and replace them on the fly on next execution.

Think about Cannon Fodder, for example. I think that many of us enjoyed it. But why should we play again exactly as it is? Wouldn't it much better to play it with modern graphic and sound, while keeping the same mechanic (the original code is still there running)?

So, the idea behind the virtualizer is about going well beyond the current emulation. Which is also enhancing in some aspects the original platform, and this is very good, but... not good enough IMO!
Quote:

Why does THEA500 need a 1-2GHz CPU with 256MiB of memory to emulate an Amiga 500 with 7MHz 68000 and 1MiB of memory?

Because the goal is the accuracy: you need to reproduce the original platform as close as it's possible to it, quirks included. This requires A LOT of computing power, unfortunately.

But here you do NOT need a 1Ghz 68k. On the exact contrary, you need a 7Mhz 68k. And not only that: you need a 68000, exactly as it was!

In fact, Amiga games REQUIRE the original hardware.

So, if you are criticizing emulation et all because of the waste of resources, you cannot come here trying to promote ASICs with 1Ghz 68060+, because they are clearly NOT usable for playing games.

The point is very simple. You have two different types of Amiga software: games and (o.s-friendly) applications. The first ones require the original platform, whereas the second ones don't.

It means that if you want to push for an ASIC, then you need at least 3 different platforms embedded:
- 68000 (7Mhz) + ECS;
- 68EC020 (14Mhz) + AGA;
- 68060+ (1GHz+) + AGA + RTG+.
And at boot time you need to select which one to use.
Quote:

Why is the Raspberry Pi a better old school philosophical successor to the Amiga than anything Amiga in decades?

Not because of "old school", but simply because it gives what users expect: allow them to run the Amiga software.

It's the usual y = f(x) which we learned at school. Once you give the same input x, you get the expected output y. How do you implement f does NOT matter, as long as you get the SAME x, y couples. Right?

@matthey

Quote:

matthey wrote: A 5GHz 68k ASIC is unrealistic but a 1-2GHz ASIC is realistic with cooperation. I understand that JIT is a proven technology even though it is complex and error prone as can be seen by problems with UAE JIT despite being out for so long. There is a reason why JIT is left off for better compatibility on THEA500 Mini and why Toni Wilen doesn't bother with bug reports while JIT is on. Sorry, AOT compilation for new software for an Amiga like virtual machine is cringe worthy. Just compile for a bastard Amiga like system if you don't value compatibility or use JIT for the standard 68k Amiga "virtual machine" if you value better compatibility. There is a reason why UAE is more popular than AmigaOS 4, MorphOS and AROS flavors. That is all we can hope for without new affordable 68k Amiga hardware.

See above, which answers to all of this.

However and to better clarify it, UAE JIT has problems because UAE needs to emulate both chipset and processor. Accessing the former creates problems. Problems can also come with badly written software.

You cannot have a single solution for all such cases, which are very different.

UAE's JIT can be tuned / specialized depending on the specific code to execute. But then it's more on the users' hands, to use the right one or configuration.

Last edited by cdimauro on 15-May-2022 at 07:57 AM.

@matthey

Quote:

matthey wrote: A 5GHz 68k ASIC is unrealistic

Yes, it most certainly is. But in my defence though, I didn't suggest it, you did in the post I was responding to.

Quote:

but a 1-2GHz ASIC is realistic with cooperation.

Sorry, but no. No it isn't. It is contingent up on the alignment of interests of different groups of people that do not have any such interest. And even if you could convince the right people to design it, bankroll it and manufacture it, nobody is going to see a meaningful return on their investment because frankly a GHz class 680x0 is going to need more than just the ASIC. You'll end up producing another custom motherboard to run it on. Even if the ASIC is cheap, the end product won't be. Sure, I was excited about the BoXer. 25 years ago. The Atari community have a better ecosystem for this.

Even if you pulled it off completely and somehow made a product that was break-even viable, a true GHz class 68K platform with commodity hardware slots and the ability to run every nostalgic 68K operating system out there from AmigaOS, MultiTOS, Human68K, QDOS, Debian 68K, Amiga Unix. The lot. Once you've sold them to the initial round of interested parties, it'll dry up. What are you going to follow it up with? How are you going to keep it relevant? Your monster 68K platform, as awesome as it would be, would end up becoming another dead end in a few more years. We don't need more dead-ended hardware solutions.

Quote:

I understand that JIT is a proven technology even though it is complex and error prone as can be seen by problems with UAE JIT despite being out for so long. There is a reason why JIT is left off for better compatibility on THEA500 Mini and why Toni Wilen doesn't bother with bug reports while JIT is on.

There's a key difference. Firstly, there is more than one JIT solution available, and most are open source. Anyone can contribute to fixes. Your ASIC will have bugs too. Real 68K processors have them. My MC68040 has them - move16 produces trash on certain accesses that I had to write explicit workaround code for in some copyspeed pixel conversion routines I had written. The bugs in your ASIC will be there, forever. This is why FPGA makes more sense as a hardware solution. Bugs can be fixed.


Quote:

Sorry, AOT compilation for new software for an Amiga like virtual machine is cringe worthy. Just compile for a bastard Amiga like system if you don't value compatibility or use JIT for the standard 68k Amiga "virtual machine" if you value better compatibility. There is a reason why UAE is more popular than AmigaOS 4, MorphOS and AROS flavors. That is all we can hope for without new affordable 68k Amiga hardware.

You just don't get it, do you? How can I spell it out for you? The point is not that new software is just for AOT compilation. It's to run on everything: 68020+, FPGA, Emu68K, UAE, Amithlon, AmigaOS4, MorphOS, some emulation platform that doesn't even exist yet. The 68K binary format becomes a universal way to distribute software for a dozen different physical architectures. AOT is a nice to have for non-native execution, but JIT is good enough as it is already.

Do you know what's truly cringeworthy? Reading the sort of fantasist drivel about providing GHz class ASIC solutions and making comparisons about how they'd perform compared to an emulation.

Emulations exist. Your ASIC does not. I'd take 1/3 the native performance of a half capable modern ARM CPU over 100% the performance of a figment of someone's deluded imagination any day. So what if it's 1/3 the performance of 100% native ARM code? As a developer, with limited time and resources, do I really want to maintain multiple CPU versions of a given piece of software intended to run on Amiga compatibles? Of course not. And in any case, is 1/3 the limit? There's no hope for improvement? Of course not, it's software and it can improve and maturate in a way a hardwired one off custom chunk of silicon can't. Finally, 1/3 the native performance of that CPU is already significantly in excess of the fastest 680x0 hardware currently available. Provide an Amithlon style native code pass-through and provide proper ARM native optimised datatypes and libraries to gain additional performance.

Your criticisms of UAE are also meaningless in this discussion since we are talking only about CPU and not whole system emulation. I wrote a lot of 68K software that did CPU and memory intensive things back in the day because I wanted to produce the most efficient graphics and audio processing I could. I was hugely dissatisfied with the performance of existing RTG when dealing with such conversions so I wrote my own. Copyspeed conversion of unsupported pixel formats directly from RAM to VRAM (on a bus already much faster than the peak ChipRAM write speed) for example. Other stuff too, such as 16 bit sound mixing of multiple channels of in-memory compressed DPCM audio because I intended to use it in a game engine. If it wasn't limited by at least one or other of the memory write or read bandwidth it was reworked, again and again. You can't stop someone on the spectrum when they have an objective like this in mind and I was relentless.

The same code under UAE was, of course far faster, but ultimately was of no significant benefit as ceiling was so high for that the naive p96 code and my code ended up IO bound. However, yet faster again was Amithlon. I got curious and made x86 native versions of that code. To keep it fair I didn't use any explicit vector intrinsics. Do you know what the outcome was? Amithlon ran the 68K code to within 70% of the equivalent native performance.

I would choose 70% the single core native performance of a modern x64 processor over your hypothetical GHz ASIC because I can't run actual code in your imagination. Which is the only place your ASIC exists and if I were a gambling man, would wager the only place it ever will. Meanwhile, ARM, AMD and intel are pumping out proven solutions every single day.

Last edited by Karlos on 15-May-2022 at 12:17 PM.
Last edited by Karlos on 15-May-2022 at 12:07 PM.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: Emulations exist. Your ASIC does not. I'd take 1/3 the native performance of a half capable modern ARM CPU over 100% the performance of a figment of someone's deluded imagination any day. So what if it's 1/3 the performance of 100% native ARM code? As a developer, with limited time and resources, do I really want to maintain multiple CPU versions of a given piece of software intended to run on Amiga compatibles? Of course not. And in any case, is 1/3 the limit? There's no hope for improvement? Of course not, it's software and it can improve and maturate in a way a hardwired one off custom chunk of silicon can't.

Indeed. It's possible, for example, to combine / fuse sequences of instructions to make the code much faster than the original.

Or, on the opposite side, to unroll loops which aren't unrolled to get more performances, if the native architecture better works with unrolled loops.

Finally, having the possibility to collect information at runtime could further improve the generation of better native code, even better native the original one.

Whereas an ASIC, as you said, is set in the stone. And if you want to change it then you need another mask -> other big money required.

Not even counting that no 68000 / 68EC20 / ECE / AGA HDL is available, so if compatibility is THE most important thing, then you're not able to build an ASIC for/with them.

@all

Before Commodore released the Amiga 1000 the Amiga Developer Team build an Amiga Emulator
in Hardware Form!

We have got the ####ing best Amiga Emulator: WinUAE!

When WinUAE reaches 100% Accuracy it will be Time to go beyond!

WinUAE .. better than the real thing! WinUAE Beyond!

! Beyond better than the real thing !

Quote:

matthey wrote: MEGA_RJ_MICAL Quote: Why should anyone think that a pluri-banned peddler of wheels who runs a year-1995 html-0.9 website and can't even get basic spelling right on the very first section of the homepage - would be a savvy source of knowledge on SOCs, emulation, instructions and architectures? I am not the webmaster of the website anymore although I did most of the work on it including designing the logo, mostly done on the Amiga. Yes, the HTML standard I used was the minimal necessary. It worked on old browsers from the '90s and modern smart phones while the minimal page sizes gave fast loading times. No pop ups, no cookies. Less was more without the bloat. The website was not my main responsibility. I primarily made steel wheels for agriculture use.

I,
friend matthey,
applaud your composure.

May the steel wheels for agriculture market shine of you with double digits year-on-year growth.


/mega!












ps. however saying "I am not the webmaster anymore" as an excuse for the abomination below,
is like Jeff Bezos saying "I am not a web developer anymore" and letting his company's homepage say
"AMZAON!!!!!!!!!!!!!!!!!!!!!!!!!1" in comic sans

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

@MEGA_RJ_MICAL


You are ####ing right! At least one of the Amiga Websites should be
as Modern as Possible!

Let`s fund Amigaworld.net!

When I win the Lottery I donate 10.000 $ *smile*

I already donated 5 Pounds 2 weeks ago or so!

Last edited by QBit on 16-May-2022 at 03:25 AM.