Quote:

kolla wrote: You are confusing "NG" with OS4.

I basically just said AmigaOS 4.x only moved us half way to NG.

Quote:

Hyperion is already about to drag 68k OS3 into the same mud pit as OS4.

The 68k AmigaOS 3.x and AmigaOS 4.x would benefit from moving closer together in terms of API and functionality. I hope the improved 68k AmigaOS can avoid some of the bloat and inefficiencies, especially ported bloat like .so/.dll hell. Olsen and ThoR have done a good job of cleaning up and enhancing the code so far although neither are 68k optimizers. Of course Hyperion's main developer, Hans-Joerg Frieden, worked on the Warp3D.library of which the last 68k version could be half the size (so much for the 68k's code density advantage). There is also the potential problem of Hyperion contracting of developers making a mess (perhaps affecting the use of improved Reaction from AmigaOS 4). There may still be people at Hyperion who are sabotaging efforts to backport to the 68k too.

Quote:

And PowerPC is 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.

PPC exists in current embedded systems but there are very few PPC CPUs going in new hardware. Freescale was the last producer and their mid performance embedded lineup is awful, barely PPC compatible and has much less support than ARM based hardware which has replaced it. The high performance embedded PPC CPUs are better but discontinued and compete with POWER. Spectre vulnerabilities are hastening the exit from PPC. Freescale botched the last attempt with PPC and threw in the towel. MIPS is more alive than PPC at this point. Not only are there still some manufacturers but synthesizable cores can be licensed for custom embedded hardware. PPC is dead!

The 68k may receive more CPU development than PPC at this point. There are other 68k FPGA cores than the Apollo core as you know. Even a 68030 performance level is enough for purely retro hardware, light general purpose use and even some embedded applications.

Last edited by matthey on 01-Sep-2018 at 12:45 AM.

@wawa

Quote:

wawa wrote: @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?

Yes? What are you trying to tell me? Matthey is convinced he can win back NG users to 68k, even though there is no 68k to win NG users back on. I point out that "NG" is a lot more than just OS4, and that it is a heck lot more likely that OS4 users go to MorphOS (especially with MorphOS appearing on more so called "OS4 hardware"). BigD brings up Vampire, as some sort of trump card (which it isn't), despite having zero experience with using any Apollo Core himself. And then you jump on this bandwagon, to tell me ... what exactly?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@wawa

Quote:

still almost ten times as much as aros needs with the same content.

Hm, really - AROS on 3MB of RAM, including networking stack, RTG and desktop?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

BigD brings up Vampire, as some sort of trump card (which it isn't), despite having zero experience with using any Apollo Core himself

I've seen the YouTube videos and it looks fast and fun and allows Alien Breed 3D 2 to be plaed at a decent speed for the first time ever on a real Classic Amiga! That in itself is a great achievement considering it always ran like a dog and is hard to emulate.

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

@kolla

Quote:

kolla wrote: @wawa Quote: still almost ten times as much as aros needs with the same content. Hm, really - AROS on 3MB of RAM, including networking stack, RTG and desktop?

given aros needs around 1.5mb with no s-s it might be possible to load workbook and arostcp (no mui/zune gui th this time of course) and send ping to the net with your specs. as i said, stripping os4 to as low requirements i mentioned, involved no s-s and in effect resignation on any gui file manager, be it workbench.

actually, you should know better, arent you running aros on mist or mister?

(btw. there is an ata.device update underway, it might be worth to test it doesnt solve your setup woes without scsi.device being patched in)

@wawa

Quote:

stripping os4 to as low requirements i mentioned, involved no s-s and in effect resignation on any gui file manager, be it workbench.

That must be me you had in mind.

I think I also loaded WB back then, but memory requirements certainly aren´t problem now for NG hardware. RAM is cheap.


Lack of modern software is the main problem of the Amiga platform. I regularly used IBrowse under WinUAE, now many sites can´t be viewed due to SSL problems. Then I tried NetSurf 68k, what a horrible experience! If 68k crowd wants to get back NG users, useable browser should be their first priority. If network speed in WinUAE/OS4 was not that abysmal, I would leave my OS3 "power configuration" for good as Odyssey (even the OS4 version) is really good browser.

@megol

Quote:

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?

Standard C (and most other languages) are not designed for the support of highly specialised machine code.

A 'swap register' command might be usable but you have to change a lot on the compiler for supporting it.

Special commands for handling RGBA Pixels or Audio values could only be implemented as functions using in-line assembler.

[code]
Think of:

RGBAnew = AddRGBA(RGBA1, RGBA2 );

instead of

RGBAnew = RGBA1 + RGBA2;

[/code]

As these function and extensions are no standard lib.c functions therefore no code will use them by a simple recompile.

I don't think these 68k ISA expansion will lead to a major speed-up on existing programs, and I don't believe coders will compile new versions of the software, they had abandoned 25 years ago.

---

On the other side the 68060 CPU is overpriced, maybe not available and restricted to low clock frequencies. A 68060 like CPU, fast RAM access and a fast chunky GFX can do wonders on the Amiga. That's why the Vampire can make sense for the retro market.

To AmigaNG:

AmigaNG should always be more than just a port to another platform, it was not only done for speed or hardware availability, it promised new concepts for AmigaOID OSes, that might compete with Windows and Linux.

But to be honest, AmigaNG failed to attract new users, new software companies and the systems are not more than improved AOS3.x ports. The improvements are on a very low level somewhere around Windows98 ...

But that's still more than you will get with a Vampire System under AOS3.x.

Last edited by OneTimer1 on 01-Sep-2018 at 10:01 AM.

@pavlor

Quote:

That must be me you had in mind.

i dont think so. the discussion was afair once on eab and then once more on a1k. however they bent that and twisted to tune it down to a minimum (im always only referring to regular requirements aros has by default, with or without s-s, i have not been removing backdrops or skins or any kickstart modules to conserve memory) memory requirements of aros remain few times lower than os4.

@matthey

Quote:

(so much for the 68k's code density advantage).

But who care about code density when you have 1000 x memory of A1200,

Quote:

Freescale was the last producer and their mid performance embedded lineup is awful, barely PPC compatible

Deepening on how you look at it. the FPU is old technology, SIMD like SPE has big advantage compared to an old FPU, you do double the work in the same time. The only drawback not being backward compatible.

If open source if there are developers who interested in compiling for it, then it's not issue at all.

Anyway picking CPU's with and with FPU's and picking CPU's with and with AltiVec makes it harder for developer to do good optimizing that’s true, it can easily tripped the work.

Quote:

The 68k may receive more CPU development than PPC at this point.

Well If your taking about 68080, it is as fast as my E-UAE jit running on my AmigaONE-X1000, and that an emulated classic system.
The development on 68080, is maybe improvement over 68060, but compared to G4/AltiVec, G5, PA6T-1682M/AltiVec (dual core CPU), 5020 (2 cores), 5040 (4 cores). This are CPU's clocked at a lot higher clock frequency, even when using just one core, the 68080 just can't compete.

You get low end or high end PowerPC from ebay at good price to run MorphOS. Even if development sopped on Power / PowerPC, the old CPU' nock the socks out of 68080's

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

@wawa

Chip ram emulation and Petunia JIT cache takes about 50MB, even before the OS has started.
(disabling this will free lots of RAM).

AROS 680x0 don't need JIT cache so will use lot less RAM.

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

@OneTimer1

If an array, maybe a picture you might want to use AltiVec to do color conversion.

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

@NutsAboutAmiga

Quote:

Chip ram emulation and Petunia JIT cache takes about 50MB, even before the OS has started.

if thats the case it is first explanation i come across that sounds sensible.

@Hypex
Quote:

Hypex wrote: @matthey 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.

The new VMX2 doesn't break any standard: it's a new, totally compatible, way to use the existing resources (e.g.: FPU and Altivec registers).
Quote:

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.

It depends on how you design the LE opcode structures. x86/x64 opcodes aren't difficult to read, because everything is byte-based, and you just read from the first (little end) byte to the last one, sequentially.
Other LE ISAs might be designed in a more contorted way, but this could apply to BE ISAs as well (bad ISA designs don't need to be LE ).

In general, for any LE ISA, the difficulty to read the opcodes is represented by 32-bit offsets/displacements, 64-bit absolute values, and 16/32/64-bit immediates, because you, as a human being, need to convert them in BE to better understand them.
Quote:

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.

Usually you find this kind of instruction on the brand new vector-length agnostic SIMD units/ISAs.

@matthey

Quote:

matthey wrote: 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.

That's horrible. I prefer 68K registers naming convention because this ISA is not orthogonal, since data and address registers aren't fully interchangeable.

Instead, homogeneous registers names should only be used on ISA which are (almost all) orthogonal.
Quote:

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).

In reality Motorola broke backward compatibility with each new 68K member family, either changing the supervisor mode or even the user mode.

So, there's no surprise that Freescale (former Motorola) continued this way with PowerPCs CPUs, like the Tabor one: it's part of its DNA breaking compatibility with the past...
Quote:

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.

In fact compatibility was/is kept. At least here, with VMX2.

And conflicts are unlikely to happen, because VMX2 code isn't usually intermixed with regular FPU and/or Altivec code.
Quote:

As I recall, the x86/x86_64 SIMD instructions are up to 6 bytes in length not counting prefixes and data extensions

With SIMD instructions you almost always need to use prefixes, because they define the kind of instruction to use out of the "basic" one (which usually is the MMX one. But newer instructions mostly aren't applicable to MMX).

Talking about the "base" SIMD opcode, you range from the 2 bytes (0F + opcode byte) + mod/rm byte of MMX, to max. 3 bytes (0F 38 + opcode byte, and 0F 3A + opcode byte) + mod/rm byte of some modern instructions. So, the minimum, "base" SIMD instruction length goes from 3 to 4 bytes (the mod/rm byte is always required).
Quote:

but they have many outdated SIMD instruction sets like MMX with tiny 64 bit registers wasting encoding space

There's not that much waste of encoding space, because there are only a few MMX instructions which were allocated in the 0F xx opcode space. The rest is used by general purpose instructions, and SSE ones.

Yes, using them would have shorten the corresponding SSE versions, but it wouldn't have changed the length of the vast majority of SSE instructions.
Quote:

(at least Altivec started with 128 bit registers).

Well, no surprise, since it came after MMX...
Quote:

The 68k could avoid this waste by starting with at least a 256 byte wide SIMD unit.

Exactly. And maybe an instruction to set the vector length. This helps a bit saving some space in SIMD instructions opcodes, albeit it's not enough to keep a 32-bit fixed length (plus EA word extensions) if you want to put all relevant and important features which a modern SIMD ISA should have (see my previous posts about it).

@megol

Quote:

megol wrote: @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.

Exactly.
Quote:

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

That's why I've suggested to use the qsort function in the C stdlib. This will be a fair comparison, since you are using exactly the same code on all architectures, with the same stdlib code, and the same compiler.

But Gunnar likes too much cheating to promote as much as possible his micro/-architecture...

@wawa

Quote:

wawa wrote: @pavlor Quote: That must be me you had in mind. i dont think so. the discussion was afair once on eab and then once more on a1k. however they bent that and twisted to tune it down to a minimum (im always only referring to regular requirements aros has by default, with or without s-s, i have not been removing backdrops or skins or any kickstart modules to conserve memory) memory requirements of aros remain few times lower than os4.

A fair comparison would be to use exactly the same AROS version, compiled for 68K and PowerPC.

Comparing OS4/PowerPC with Amiga o.s. 3.x/68K isn't fair at all, since they are quite different.

Anyway, with all memory which is available nowadays, I don't know how much sense has fighting only for a bunch of +/- MBs...

@matthey

The newest AVX 512 with the EVEX encoding can have 6 bytes for the main opcode, sure. 4 bytes EVEX + 1 byte opcode + 1 byte modR/M. You aren't likely to see any other prefixes with that given that one of the objectives with the EVEX and the VEX prefix/format is to remove unnecessary prefixes.

I don't really agree with prefixes not being useful for 68k, the advantage with a prefix is that existing instructions needn't be replicated in a new, longer, format to be extended. And a prefix can be both faster and shorter than existing code without having complicated fusion of instructions in the processor.

It seems it doesn't matter anyway. The only 68k core being updated now is AFAIK the Apollo core and while they claim to be working on OoO execution it feels like a dead end. Nice for some semi-retro fun but not for NG developments.

Quote:

megol wrote: The newest AVX 512 with the EVEX encoding can have 6 bytes for the main opcode, sure. 4 bytes EVEX + 1 byte opcode + 1 byte modR/M. You aren't likely to see any other prefixes with that given that one of the objectives with the EVEX and the VEX prefix/format is to remove unnecessary prefixes.

Yes, I was talking about 6 byte AVX instructions. There must be significant cost to the prefixes if they are wanting to reduce the number of prefixes even as the instruction length grows. From what I have read, the long SIMD instructions have been a performance problem for low end Atom CPUs. I hope the 68k doesn't need 6 byte SIMD instructions too. There is a lot of F-line encoding room but a SIMD unit needs plenty, especially with 3 op and many registers.

Quote:

I don't really agree with prefixes not being useful for 68k, the advantage with a prefix is that existing instructions needn't be replicated in a new, longer, format to be extended. And a prefix can be both faster and shorter than existing code without having complicated fusion of instructions in the processor.

Prefixes make sense for x86_64 but the prefixes are only a byte, prefixes were needed for adding 8 more registers from x86 to x86_64, x86_64 was out of encoding space, byte decoding is already less efficient and once prefixes were supported it was cheap to allow more prefixes. Prefixes are useful for altering the original instruction template. The 68k could add 16 more registers with a prefix but it seems like a waste to decode and use 2 of 16 bits with a prefix. I don't think 16 more registers is necessary or worthwhile. Longer instructions certainly have a cost too. Instruction data in an added extension word is cheap but decoding data and register ports in an added extension word likely has a cost similar to a prefix.

Quote:

It seems it doesn't matter anyway. The only 68k core being updated now is AFAIK the Apollo core and while they claim to be working on OoO execution it feels like a dead end. Nice for some semi-retro fun but not for NG developments.

I hope you are not implying that the OoO execution feels like a dead end. OoO for longer latency instructions like integer division and FPU instructions is cheap and should give a modest boost to performance. Apollo core instructions are not broken down as far as x86_64 and most of the integer instructions are single cycle in order for simplicity and energy efficiency. Gunnar has CPU design talent but lacks professionalism.

@NutsAboutAmiga

Quote:

Even if development stopped on Power

Development of Power9 and future Power variants is continuing.
Raptor Engineering has just released a teaser photo of a single cpu MATX system that could be priced low enough to be competitve with the X5000.

Since a quad core Power9 cpu supports 16 concurrent threads, it's well past time that we get SMP support for NG OS'.

If we could get out of this hobbyist mentality, we really could have a shot at creating a viable alternative platform.

Look, I love the 68K. I built and sold systems based on it, and still work on projects based on those cpus to this day, but that's a hobby.
As was pointed out, even an old PPC dances circles around a 68K processor.
And Power9 thrashes old PPC cpus.

Plus, we have THREE NG OS' that could be ported to that platform.

So...68K as a great legacy/hobbyist platform, AND there ARE new Power systems we can move to.
On top of that, they are competitive with modern hardware.

I, for one, will not deign to disparage where we've gone. We provided an alternative to Wintel and we still do.

Last edited by JimIgou on 04-Sep-2018 at 02:58 AM.

Quote:

JimIgou wrote: ..So...68K as a great legacy/hobbyist platform, AND there ARE new Power systems we can move to. On top of that, they are competitive with modern hardware. I, for one, will not deign to disparage where we've gone. We provided an alternative to Wintel and we still do.

+1

Last edited by klx300r on 04-Sep-2018 at 03:54 AM.

_________________
____________________________
c64-2sids, A1000, A1200T-060@50(finally working!),A4000-CSMKIII
! My Master Miggies- Amiga 1000 & AmigaOne X1000 !
mancave-ramblings
X1000 I BELIEVE

@matthey

Quote:

Yes, I was talking about 6 byte AVX instructions. There must be significant cost to the prefixes if they are wanting to reduce the number of prefixes even as the instruction length grows. From what I have read, the long SIMD instructions have been a performance problem for low end Atom CPUs. I hope the 68k doesn't need 6 byte SIMD instructions too. There is a lot of F-line encoding room but a SIMD unit needs plenty, especially with 3 op and many registers.

No it isn't a significant cost and if there were they would still be there as the old encoding is still supported. The EVEX format supports more registers and both it and the VEX format is designed to open up more instruction space without needing any type of hacks (like some SSE instructions used).

The 68k wouldn't need it of course however it wouldn't be a huge problem if it did. While 6 bytes may sound much the Itanium used 5 bytes (+ some extra) for every instruction without that being a bottleneck, for 68k 6 bytes instructions would be an exception rather than a rule.

Quote:

Prefixes make sense for x86_64 but the prefixes are only a byte, prefixes were needed for adding 8 more registers from x86 to x86_64, x86_64 was out of encoding space, byte decoding is already less efficient and once prefixes were supported it was cheap to allow more prefixes. Prefixes are useful for altering the original instruction template. The 68k could add 16 more registers with a prefix but it seems like a waste to decode and use 2 of 16 bits with a prefix. I don't think 16 more registers is necessary or worthwhile. Longer instructions certainly have a cost too. Instruction data in an added extension word is cheap but decoding data and register ports in an added extension word likely has a cost similar to a prefix.

Using only two bits would be a waste which is why I have sketched many different types of prefixes to reduce waste. But none of those use only two bits, the smallest used 6 bits IIRC out of the 11 available in the Coldfire MVZ/MVS space.
So it would be possible to add 64 bit operations, 16 registers (each of Ax, Dx), sign/zero extension and other features to the standard instruction set. This would partially compensate the larger instructions however what features to include would need a simulator plus compiler support to decide.

I've looked at changing instructions with extension words but that is a huge pain to do effectively as the location of extensions words require decoding the first instruction word. So partial decode + extraction of extension word + detection of special extension word and changing of the decoded instruction. There would be other problems including detecting that a memory operation is actually using a new extension word.

Quote:

I hope you are not implying that the OoO execution feels like a dead end. OoO for longer latency instructions like integer division and FPU instructions is cheap and should give a modest boost to performance. Apollo core instructions are not broken down as far as x86_64 and most of the integer instructions are single cycle in order for simplicity and energy efficiency. Gunnar has CPU design talent but lacks professionalism.

I meant the Apollo core/project. Still they are the only ones AFAIK that are actually doing a 68k update.