@matthey
Quote:

matthey wrote: A full orthogonal CISC encoding with 16 GPR (r0-r15) registers uses substantial encoding space. With a variable length 16 bit encoding, it would require more of the encodings to become 32 bit encodings. The An and Dn specialization allows for the 68k awesome code density, 16 registers without reducing code density (tiered system where instruction sizes grow when using r8-r15 like x86_64 is unnecessary) and significant encoding is available. The 68k EA encoding practically has a 4 bit register encoding. The EA consists of a 3 bit mode and 3 bit register encoding. %0000 d0 r0 ... %0111 d7 r7 %1000 a0 r8 ... %1111 a7 r15 Many of the EA encodings use An *or* Dn as the register file was split on the 68000 (outdated on pipelined 68k CPUs like the 68020+). The ISA can be enhanced to allow An *and* Dn in most sources effectively giving a 4 bit register encoding. EA destinations could usually be opened also but allowing An destinations would require special handling of condition codes as An operation destinations usually do *not* set the condition codes as Dn destination operations do. Opening EA sources provides most of the benefits (fewer instructions, improved code density and better orthogonality) while preserving the "feel" of the 68k.

x64 is a big patchwork: no wonder of this code density decrease when using the new registers.
However a re-encoding/rewriting of the ISA allows to match the 68K code density, but with 32 GPRs available with almost always orthogonal usage (and 64 fully orthogonal SIMD registers with 128..1024 bits vector sizes, plus 8 masks registers). Plus 3 operands encodings and 3 operands with 8-bit sign-extended value as second source, which can be further used to improve code density and/or performances.

Regarding the 68K, there are several encodings where only Dn registers are used. If you want to extend/orthogonalize the ISA in order to use An as well, you need to use a 32-bit opcode, thus decreasing code density in this case.
On the other side, the EA modes where only An is used as base aren't extendible to Dn registers, unless you want to use a prefix (which you don't want). Using Dn as base (and without using indexes) register in EA is possible, but at the expense of worse code density.
Last but not least, AFAIR only LEA can be extended to use Dn as target; there should be some 16-bit encoding space available.
Quote:

Quote: That always with the primary goal to accelerate existing applications. Because this is the crude reality: it's very unlikely that new applications will be created to make use of "alien" Amiga technologies, like 64-bit, Hyperthreading, SIMD. Isn't that true for next gen Amigas also? A few hundred active users is not enough to attract development and much of what we do get is just "alien" shovelware instead of Amiga innovation.

Yes, I fully agree. And the post-Amiga scene is fragmenting even more...

@kolla

Quote:

kolla wrote: @michalsc Quote: And because on linux there is second set (32bit one) of necessary libraries. Yes, people seem to not understand (or somehow forget), that running 32bit on 64bit Linux means having two OS installations on the disk, one 64bit and one 32bit.

True, but the (real) point is that at least this is possible with Linux and Windows, and you can mix 32 and 64 bit apps, sharing many resources.

Something which CANNOT be made with the Amiga o.s., due to its intrisic bad design.

@cdimauro

Not shooting at you, but most times when I read one of your posts, it feels like you really dislike AmigaOS and you often mention "the intrinsic bad amigaOS design".
That won't change for sure at least until AmigaOS 5.. ;)

Anyway, what is there you like about AmigaOS?

@Amigo1

Quote:

Amigo1 wrote: @cdimauro Not shooting at you, but most times when I read one of your posts, it feels like you really dislike AmigaOS and you often mention "the intrinsic bad amigaOS design".

I'm an amigan from very long time (1987), but I've acquired a lot of experience with other systems/platforms too, so I'm able to make critical comparisons and provide a reality check.

I think that we all enjoyed the "good, old (Commodore) days", and were fascinating by the beautiful machines that were our Amigas, because they gave us A LOT of emotions.

Our systems were extremely fast and responsive, and we were delighted of it.

However this came because of the o.s. design choices that I was talking about : they gave an immediate benefit / results, but the price to pay was paid after some years, and the o.s. evolution was crippled.

This is something which I, as an amigan, am sad. And that's what I substantially express: a mixture of sadness, delusion, and rage. I dreamed about a better evolution for my favorite platform, but the more the knowledge I've acquired, the more I've realized how bad is the reality...
Quote:

That won't change for sure at least until AmigaOS 5.. ;)

I'm waiting 2 more weeks.
Quote:

Anyway, what is there you like about AmigaOS?

Volumes/assigns, data types, the CLI, "one library version/interface to rule them all", resident commands, a rich set of built-in libraries... are the first things which came to my mind.

I think that an Amiga o.s. successor or an inspired one should have at least those.

@matthey

Quote:

The An and Dn specialization allows for the 68k awesome code density, 16 registers without reducing code density (tiered system where instruction sizes grow when using r8-r15 like x86_64 is unnecessary) and significant encoding is available.

I thought I may have read about a (Dx) extension to relax the restrictions but can't find any info on it

Quote:

The 68k EA encoding practically has a 4 bit register encoding. The EA consists of a 3 bit mode and 3 bit register encoding.

I was confused to what your Dx to Rx was but figured it out.

Quote:

EA destinations could usually be opened also but allowing An destinations would require special handling of condition codes as An operation destinations usually do *not* set the condition codes as Dn destination operations do.

Yes that was a useful feature of using an address register if you needed to move but preserve flags.

Quote:

The Altivec and FPU register files may be unified on particular designs but the ISA does *not* force any unification that I'm aware of.

We know what trouble unification can cause. No AltiVec. No FPU. SPE. Breaking standard registers doesn't look like a good idea.

Quote:

There is no need for a prefix on the 68k for an FPU or SIMD unit.

Postfix then?

When I think about it x86 would need a prefix as being little endian it is byte based. So it all begins at the little end. However I imagine LE instruction coding would soon become a nightmare. The whole instruction code can't be read in and decoded since it would be divided up into parts and any subcode over a byte would need to be read in as LE as it goes along. So this goes from a LE memory read to a need to interpret the cache as LE in parts. Though likely the codes are written backwards or kept in byte fragments aside from data.

OTOH on the 68K it's all words. Read the words into the cache and go along each word. No need to think about different parts of the cache being reversed.

Quote:

The x86_64 SIMD ISAs have sometimes masked half of the SIMD register width for compatibility with narrower sizes when doubling their SIMD unit register wi

I would have thought there would be an instruction to set width like there is an instructionbs to move into protected mode and run enhanced.

Quote:

At the user level, there is not much difference between the 68040 and 68060 and not much added to these CPUs.

Mostly different binaries being used for 040 and 060.

Oh you meant user code?

Quote:

The 68060 did make some significant supervisor changes.

Quote:

Isn't that true for next gen Amigas also?

I wouldn't say so. OS4 is now reaching breaking point. Of the 32-bit OS it is based on. It needs to move on. Since the point of OS4 isn't to run all the classic applications and old games with the same limitations. The point is to run AmigaOS as a newer interface on more modern hardware allowing futher expansion now and in the future.

Quote:

Hypex wrote: I thought I may have read about a (Dx) extension to relax the restrictions but can't find any info on it

The 68020 ISA removed a few limitations. It became possible to use a data register like a base register for some addressing modes although it is slower and often larger. An address register can be tested. These did make the ISA more orthogonal. The 68020 ISA is a significantly easier target for compilers but a few of the features should have been avoided as they can't be fast in hardware.

Quote:

I was confused to what your Dx to Rx was but figured it out.

I have seen code which referred to the 68k registers as r0-r15. It may take some getting used to use d0-d7 and a0-a7 but it is easier to keep them organized where they lack orthogonality and the register names are consistent length and sometimes shorter.

Quote:

Yes that was a useful feature of using an address register if you needed to move but preserve flags.

The 68k address registers act much like RISC registers with the auto sign extension to register width and no condition code as default. This is fast avoiding some stalls but data registers are more flexible and powerful. It is nice to have both types of registers.

Quote:

We know what trouble unification can cause. No AltiVec. No FPU. SPE. Breaking standard registers doesn't look like a good idea.

The Tabor CPU abandoned both the AIM PPC ISA and ABI and in a way which made compatibility difficult. Freescale should have renamed these CPUs PPCE or something else to accurately reflect the lack of PPC compatibility. The 68k, x86, and ARM 32 bit CPUs will run code for their respective ISAs from practically the first CPU which supported the 1st version of their ISAs (compatibility sometimes being broken when they introduced 64 bit ISAs and ABIs). Old 32 bit PPC code on the Tabor 32 bit PPC CPU won't run though. It looks to me like false marketing to claim these CPUs are PPC compatible.

Unification of register files has advantages and disadvantages. The way the POWER ISA unified the FPU and SIMD registers allows for more combined registers than the same resources would give if they were separate but conflicts between the units for resources can reduce parallelism. Compatibility should be a primary concern.

Quote:

Postfix then?

The 68k uses a variable length encoding so longer instructions can be added if encoding space is needed. There is no need for a prefix or postfix with a newly created encoding. They are more commonly used to "fix" mistakes and limitations of old encodings.

As I recall, the x86/x86_64 SIMD instructions are up to 6 bytes in length not counting prefixes and data extensions but they have many outdated SIMD instruction sets like MMX with tiny 64 bit registers wasting encoding space (at least Altivec started with 128 bit registers). The 68k could avoid this waste by starting with at least a 256 byte wide SIMD unit.

Quote:

I wouldn't say so. OS4 is now reaching breaking point. Of the 32-bit OS it is based on. It needs to move on. Since the point of OS4 isn't to run all the classic applications and old games with the same limitations. The point is to run AmigaOS as a newer interface on more modern hardware allowing further expansion now and in the future.

Moving on is likely to leave most of the Amiga users and software behind. Moving back to retro goodness and reuniting with classic Amiga users left behind looks better to me.

@cdimauro
Quote:

It's even worse: the code is specifically written to exploit the Apollo 68080 microarchitecture. That's why it loads the two values to be checked, checks & swap them if this is the case (which always is, since the data are always filled in the reverse order), and then always writes back to memory both. If you take a look at the comment which reports the 68K assembly, this is quite evident. In fact, the "if" & "swap" is basically represented by two instructions: a conditional branch followed by the exchange. Those instructions are merged together by the Apollo core, and internally transformed in a single instruction which is conditionally executed (like 32-bit ARM, to be more clear). It means that the Apollo core will NEVER introduce bubbles in the pipeline due to a branch misprediction (like it happens on other architectures which have not such kind of mechanism), because... there are no branches at all! And this happens in the most important (and critical to performances) part of the Bubble sort.

That the C code is written in pseduo-assembly format is also suspect: why not write standard C code that should generate good code with a competent compiler?
The only logical reason I can see is they designed the assembly code first and then tried to get the compiler to generate it.

Would be interesting to see if normal code would make a difference.

Last edited by megol on 31-Aug-2018 at 06:48 PM.

@matthey

Quote:

Moving back to retro goodness and reuniting with classic Amiga users left behind looks better to me.

I can not imagine any "NG" user who would ever want to go back to classic. Why on earth would they want to do that?

Last edited by kolla on 31-Aug-2018 at 07:20 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: I can not imagine any "NG" user who would ever want to go back to classic. Why on earth would they want to do that?

no pun intended, but that proves limits of your imagination ;)

i dont like to call out examples by their names, but observed not only ng users but notable developers dropping ng for amiga, you should recall because afair you named one of them yourself as example in one of your recent posts.

@kolla

Urgh?! You've heard of the Vampire right? Also, NovaCoder especially showed that extra performance could be extracted from the Amiga even in the last five years to really push 3D games. Imagine what he could do with the Vampire! Beats of Rage works great on a 060 Classic! These are great times for 68k 'Miggies. Worthy is a new A500 compatible Classic game! A commercial A500 OCS game that looks far better than 3D Spencer on NG! His name is Spencer for goodness sake! What is this 1992

Does Deluxe Paint V run on a NG machine for animation use? Is PageStream 5 stable on NG Amigas yet? I figure no on both counts. Also, is printer support better than with TurboPrint5 on the Classic? No again no. These are some of the reasons why the Classic is still relevant and the NG systems are getting less so by the day the longer the Tabor takes to come out

Last edited by BigD on 31-Aug-2018 at 09:17 PM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@wawa

Developers sure, they are in it for totally different reasons than what users are in it for. Many OS4 developers never left classic, but most NG users did.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@BigD

Quote:

BigD wrote: @kolla Urgh?! You've heard of the Vampire right?

Sure, I own a couple of them - do you?

Stop thinking that Vampire cards bring your classic anywhere near NG systems performance wise, they don't. Unless perhaps, if your NG baseline is an efika or powerup board.

Last edited by kolla on 31-Aug-2018 at 09:24 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

you are referring to a fraction, supposedly never to learn.. but no need justto stay assured. as apparently, you havent done it already, you might check for yourself a number of previously very vocal ng supporters that are now pretty active on lets say vampire forums or the like.

@kolla

They are fun. They allow people that don't have a 060 (I do) to play games and use software that they couldn't in the 90s. Developers have a new more interesting target to aim software at. I could go on but you obviously can't see what's in front of you

Quote:

I own a couple of them - do you?

Are you trying to sell me your spare one or something? I'll be tempted by the standalone one but I don't own a A500, A600 or even A1200 so they don't service my Classic 'Miggies with the current line up. Plus I have an 060 so it's not such a step up in performance for me. As I said Beats of Rage is great on a 060. Deluxe Paint 5 and PageStream 3 work great on a 'Miggy as does TurboPrint 5. What does a NG system do for me? I will try Lightwave 5 in the next few months and maybe that will convince me that my 060 is too slow, but maybe I won't enjoy it as much as Deluxe Paint and it still won't bother me. I play Tower57 on my Mac and will buy Worthy for my Classics in the next few months. I also have next Brian Bagnall book to look forward to!

Tell me what I am missing? Spencer? The new Wings? What? Surely lots of developers feel the same way. It's like the demo scene; challenge yourself to squeeze performance out of a limited but fun computer. The Vampire has pushed the bar and people are inspired. 'Nuff said

Last edited by BigD on 31-Aug-2018 at 09:34 PM.
Last edited by BigD on 31-Aug-2018 at 09:32 PM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@wawa

You are the one referring to a fraction.

I don't know of any MorphOS users who drop their systems in favor of Vampire cards. They may buy a Vampire in addition, but that's more of a novelty to have fun with classic hardware they already got.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@BigD

The inspiration quickly wears off once you actually have a card and try to use it, or worse, develop on or for it. It's a novelty, it's fun if random weirdness behavior you have never encountered on any Amiga before is something you consider fun, but it is no shape or form a replacement for a NG system like a mac mini with MorphOS, or any "non classic" OS4 system, or AROS on a PC.

In terms of what I can *do* with the vamped a600 (or CDTV), the old 200MHz 604e CSPPC/CVPPC can do quite a lot with even OS4.1FE that the vampire systems can not do. For example video playback, where Vampire cards only play mpeg1 files in a satisfying matter with specific 68080/AMMX optimized software, while a handful of players can play mpeg2 files on the csppc. Playing the same same mpeg2 files on vampire using 68k equivalent software (f.ex FroggerNG) is slideshow.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Quote:

kolla wrote: I can not imagine any "NG" user who would ever want to go back to classic. Why on earth would they want to do that?

The top 10 reasons.

10) New hardware is little endian even when it claims to be bi-endian.
9) PPC is dead and the computer world is *not* missing it.
8) PPC book E isn't even PPC compatible.
7) PPC only took us half way to a NG (no SMP, 64 bit, memory protection, resource tracking).
6) The 68k is not fat like PPC (~40% better code density, AmigaOS 3.9 6MiB min vs AmigaOS 4.1 128MiB min memory).
5) The legendary 68k has more (retro and hobbyist) appeal outside of the Amiga community.
4) The 68k Amiga won't die despite the best efforts to sabotage it.
3) The 68k provides the best Amiga compatibility.
2) The 68k is easily the largest Amiga market (original hardware, FPGA hardware, UAE)
1) The 68k is the heart and soul of the Amiga.

@matthey

You are confusing "NG" with OS4.
Hyperion is already about to drag 68k OS3 into the same mud pit as OS4.
And PowerPC ia a heck lot more alive than 68k as an architecture, just not used much in consumer land. In aerospace and telecommunications it is still there. Meanwhile, 68k is a one-man show currently.

EDIT: OK, I have more time to kill now...

Quote:

10) New hardware is little endian even when it claims to be bi-endian.

So you better make sure your operating system is endian-agnostic and not tie yourself one way or the other.

Btw - Internet will remain big-endian, so expect to find big-endian hardware in rthe realms of networking.

Quote:

9) PPC is dead and the computer world is *not* missing it.

You are confusing "computer world" with "consumer market". Besides, Amiga NG is not tied to PowerPC, nor is it tied to big-endian.

Quote:

8) PPC book E isn't even PPC compatible.

So what? If you want PowerPC, there is tons of other cheap hardware to pick from.

Do NG users care whether they can have affordable and available hardware?
Some do, some clearly do not.

Quote:

7) PPC only took us half way to a NG (no SMP, 64 bit, memory protection, resource tracking).

PPC had little to nothing to do with this, all of the above was decisions made by OS developers. They would have done the same had it been some other architecture, they would certainly had done the same had 68k continued to evolve (which it btw did - the problem was Commodore, not 68k)

Quote:

6) The 68k is not fat like PPC (~40% better code density, AmigaOS 3.9 6MiB min vs AmigaOS 4.1 128MiB min memory).

Code density or just bling and capabilities? What is code/bling ratio in the above installations? For the record, when I boot OS4.1FE Classic, it does not take 128MB, it's more somewhere around 50 MB, and that is with networking stack and 24bit RTG workbench, bling bling window decor, 24bit icons, backdrops etc.

What runs away with the RAM are the web browsers, and then it doesn't matter if it is 68k or PowerPC. Maybe you should look at the requirements of the so called "modern" 68k web browsers?

In order to compare properly, you must use comparable OS configurations. I have OS3.9 system with just 3.5 MB of RAM and I also have run Linux/PPC on as little as 16MB RAM.

I recall OpenOffice for MacOS/PowerPC having roughly half the foot print (both disk and RAM) as the exact same OpenOffice for the exact same PowerPC running AIX - how can this be, do you think? Maybe architecture isn't the whole story?

Quote:

5) The legendary 68k has more (retro and hobbyist) appeal outside of the Amiga community.

Yes, but all they want are drop-in CPU replacements for their old hardware which most of the times are running proprietary retro operating systems that cannot be adopted to anything new. I know, because I asked around.

Then there are the Nintendo retro communities, don't forget that Nintendo had several PowerPC based consoles. And Sony PlayStation. And Xbox whatsitsname. They are also "retro" now.

Quote:

4) The 68k Amiga won't die despite the best efforts to sabotage it.

Neither will PowerPC.

Quote:

3) The 68k provides the best Amiga compatibility.

Debatable, it seems like all 68k variants are different from one another, to the degree that software emulation provide better and more consistent software compatibility.

Also, for NG users, the compatibility with legacy Amiga titles is not at all so important anymore, moving forward is much more important. Attracting developers from outside the asylum is more important.

Quote:

2) The 68k is easily the largest Amiga market (original hardware, FPGA hardware, UAE)

Do not confuse number of users with a market.
Market is only users willing to pay.

Quote:

1) The 68k is the heart and soul of the Amiga.

For certain developers and low level coders (quite clearly not all), perhaps. But sadly, Amiga users are very often quite ignorant and do not care one way or the other.

Last edited by kolla on 01-Sep-2018 at 12:39 AM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

I don't know of any MorphOS users who drop their systems in favor of Vampire cards. They may buy a Vampire in addition, but that's more of a novelty to have fun with classic hardware they already got.

and here we are again within your usual rant area "vampire". lets say i am visiting morph zone once upon a time, when im bored, and i dont really find or look for those who drop morphos to get a vampire, neither of which is at cost prohibiting each other. but ther is s numbrt of users who own or are interested in both which fine, i suppose?

Last edited by wawa on 01-Sep-2018 at 12:07 AM.

@matthey

Quote:

The 68k is not fat like PPC (~40% better code density, AmigaOS 3.9 6MiB min vs AmigaOS 4.1 128MiB min memory).

after i have challenged os4 users for comparatively small memory footprint aros has on amiga, they have managed to get down to much lower numbers, admittedly with a pocket of tricks such as without startup sequence and the like. i dont remember actual numbers but it might be below 30mb, still almost ten times as much as aros needs with the same content.