@Hammer

Quote:

Qualcomm Hexagon DSP is also a little endian. Hexagon DSP is used in Qualcomm Snapdragon SoCs.

How completely hat stand!

@Hypex

Quote:

Hypex wrote: @cdimauro Is that because of the extra R8 to R15 registers that make sense? On top of the R registers. Likely meaning Really extended. They must have ran out of the alphabet.

The letters were and are still a legacy from 8085.

It made sense at the time, because their purpose was explicit: A = Accumulator, D = Data, C = Counter, B = Base, SI = Source Index, DI = Destination Index, SP = Stack Pointer, BP = Base Pointer.

I find them very readable.
Quote:

Quote: GLOM. No, please! Itanium was a failure, since the beginning. It was Intels chance to break from x86. But AMD ruined it with their 64 bit extension.

Indeed.
Quote:

It's only been a few years since it dropped out of the market. Hey POWER won! It's still around! Ha! But it was complicated, being not purely RISC, not purely CISC, but some combination of both and some neither.

Well, I don't know of any RISC processors since decades: all of them are CISCs. Itanium makes no exception.
Quote:

In any case, it is what become of the HP-RISC since HP approached Intel. Like I've said before, had the Amiga survived and the Hombre been produced, it may have had an Intel inside. But it wouldn't have been an x86!

People wouldn't have loved it as well: Intel was/is (!) The Evil Enemy.
Quote:

Though Intel were working on their own x86-64 designs, the x86 was still like Simple Minds and their hit Don't forget about me. Because they were most well known for it but didn't write the song. Intel produced the x86 but in the history leading up to it, coming from the 8008 ISA with which it shares similarities in design, the 8008 ISA was not designed by them but by Datapoint. I suppose it was given to them in a way by Datapoint, since they could keep the design, and after producing and refining it into x86 for so many decades it's been big business for them.

Correct, but the subsequent 8080 was a different processor, binary-incompatible with 8008.

8086 was the same: binary-incompatible with 8085.
Quote:

This quote from the Itanium Wikipedia page is gold: "I looked Albert Yu [Intel's general manager for microprocessors] in the eyes and showed him we could run circles around PowerPC, that we could kill PowerPC, that we could kill the x86." Well, he did kill the PC in a way, the PC in PowerPC, since Itanium pretty much survived while PowerPC disappeared and only POWER remains! I don't quite see why killing PowerPC would be a big deal, was it special? And it's quite bizarre to go up to a generic manager at Intel and suggest how to kill a major product line.

I agree. But I think that the time Intel's goal was to destroy all RISC competitors. Which it succeeded for many of them. But at the end Itanium died as well: killed by x86-64.
Quote:

In future this could become a joke if it doesn't find a solid market. Why didn't quantum computers take over the world? Because they weren't IBM compatible.

LOL They'll not because they are special-purpose computers. General-purpose computers are here to stay.
Quote:

Quote: Usually yes, but since several years "vector" is used for the variable-length extensions. Since they group data they could also be A for array.

Anyway, anything but NOT D, which is used for our beloved Data registers. However A was already used for Address registers...
Quote:

Complicates the encoding, but I imagine generally vector operations are variable. At least, I would take vector to imply dynamic width, where the width of each vector in a group could be variable.

Yes, this is the New Trend: vector units are register sizes-agnostic.
Quote:

Working with non-N powers would be useful, but I don't know if even the latest 512 or 1024 width extensions can work that way, like with a packed data stream.

No, everything is implemented as powers of two: this make the implementation easier to be handled.

For non-powers of two data masks/predication are available and elegantly solve the problem.
Quote:

Quote: The 68k width protocol could be used for lane/data. But I've found another, more compact, solution for my NEx64T. Interesting name. I keep thinking back to Nintendo N64 for some reason.

No, it has nothing to do with it.

It's a pun using the words EM64T (Intel's name for its x86-64 extension), x64 (which is the most widespread name for it) and Next.
Quote:

And regarding 68K conventions, at least for FPU, each instruction was prefixed with a signifying letter.

I find it a much better way to "mark" a set of instructions. Intel did the same with its FPU instructions.
Quote:

Quote: Just extend them to 128 bit (at least)... And match PowerPC.

Which went 256-bit with its latest extensions.
Quote:

Quote: How? Mem-to-mem was only available for the general MOVE instruction. Plus there are a few arithmetic instructions with specific, fixed EA modes. So, there are no other mem-to-mem instructions on 68k. It was. There are at least EA to FP and FP to EA for FPU ops.

But those aren't Mem-to-Mem: they are just reg-mem or mem-reg.
Quote:

One way would be to encode it as a long instruction with extended codes and addresses. It would need to internally combine a few microcodes. Doing so would extend the length of encodings above the space needed for vector ops already, Convenient but not a necessary expense.

That's how I did it. NEx64T supports up to two EA, so you could have Mem-Mem, Reg-Mem-Mem or Mem-Reg-Mem. SIMD/Vector quaternary instructions could have Mem-Reg-Mem-Reg or Reg-Mem-Mem-Reg.
Quote:

Better to follow other ISAs and use something like PMOVE or PLOAD, etc.

Just make sure not to confuse it with MOVEP. [/quote]
No worry: this was already killed by Motorola.
Quote:

Quote: You don't need an account: you can get the manual by just clicking on the link (which us provided on the Apollo forum). I mean, those links that only get shared on Discord or somewhere like it's an exclusive club. Sometimes it is. Take SDK info for AmigaOS and autodocs. So these are easily found online. Plenty of 68K discussion. OS4 has plenty of resources and a forum. But when I was interested in looking up info on MorphOS I found the info hard to come by. The most info I found was looking up the AROS API where it shares functions with MorphOS. I once asked about Firewire debugging I had read about. Then was told I should ask on IRC. IRC? How about just making the info available.

I fully agree: the documentation (ALL!) should be available on the main site.
Quote:

Quote: But a much better system... VGA or C16? Or perhaps C64?

V64 = Vector64?

Where the user "Gunnar" is ?
Any clue ?

Mega, you that know everything ?

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

My article about planar vs packed graphics is finally published: Il falso mito dei bitplane più efficienti (della grafica packed/chunky)

I suggest you to translate it with deepl.com if you want a more accurate version or use Google Translate to keep the formatting (unfortunately deepl.com doesn't give this useful option).

Enjoy!

@cdimauro

What’s the TL;DR?

Proof of concept/MVP available?

@Bosanac

Quote:

Bosanac wrote: @cdimauro What’s the TL;DR? Proof of concept/MVP available?

In short: not needed. Math is enough.

Quote:

Massi wrote: Where the user "Gunnar" is ? Any clue ? Mega, you that know everything ?

Friend Massi,

I believe Gunnar is Franko.
you can find him here.

/MEGA

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

@cdimauro

Quote:

cdimauro wrote: My article about planar vs packed graphics is finally published: Il falso mito dei bitplane più efficienti (della grafica packed/chunky) I suggest you to translate it with deepl.com if you want a more accurate version or use Google Translate to keep the formatting (unfortunately deepl.com doesn't give this useful option). Enjoy!

Amiga's Dread has 4-bit planes and the C2P process is accelerated by the hardware Blitter
(ref 1).


Krzysztof Kluczek:.
Line doubling kills some perf (even when on STe it uses the Blitter), but you can disable it in options choosing "Scanlines" mode. The other perf killer is chunky 2 planar, which takes minimum CPU hit on Amiga thanks to interrupt-driven Blitter.


Yes, Blitter takes some CPU cycles, but it's a performance win as CPU can already start computing the next frame. Turning nasty bit ON causes very considerable performance drop - with it CPU no longer has that head start on next frame.

------------------

Dread runs better with Fast RAM.

Reference
1. https://twitter.com/KK_DMA/status/1435530604372705280?s=20&t=zne3zkrRyr-28u-x44ZJlw

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

Quote:

It's a pun using the words EM64T (Intel's name for its x86-64 extension), x64 (which is the most widespread name for it) and Next

In late 2006 Intel began instead using the name "Intel 64" for its implementation.

In 2020, through a collaboration between AMD, Intel, Red Hat, and SUSE, three microarchitecture levels on top of the x86-64 baseline were defined: x86-64-v2, x86-64-v3, and x86-64-v4. (1, 2)
This action codified X86-64 feature levels.

This mirrors ARMv8-A, ARMv8.1-A, and 'etc'.

Reference
1. https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level

2. https://lists.llvm.org/pipermail/llvm-dev/2020-July/143289.html

3. https://www.phoronix.com/news/GCC-11-x86-64-Feature-Levels

These common levels in their initial form amount to:

x86-64: CMOV, CMPXCHG8B, FPU, FXSR, MMX, FXSR, SCE, SSE, SSE2

x86-64-v2: (close to Nehalem) CMPXCHG16B, LAHF-SAHF, POPCNT, SSE3, SSE4.1, SSE4.2, SSSE3

x86-64-v3: (close to Haswell) AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE

x86-64-v4: AVX512F, AVX512BW, AVX512CD, AVX512DQ, AVX512VL

Last edited by Hammer on 29-Oct-2022 at 03:07 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: My article about planar vs packed graphics is finally published: Il falso mito dei bitplane più efficienti (della grafica packed/chunky) I suggest you to translate it with deepl.com if you want a more accurate version or use Google Translate to keep the formatting (unfortunately deepl.com doesn't give this useful option). Enjoy! Amiga's Dread has 4-bit planes and the C2P process is accelerated by the hardware Blitter (ref 1). Krzysztof Kluczek:. Line doubling kills some perf (even when on STe it uses the Blitter), but you can disable it in options choosing "Scanlines" mode. The other perf killer is chunky 2 planar, which takes minimum CPU hit on Amiga thanks to interrupt-driven Blitter. Yes, Blitter takes some CPU cycles, but it's a performance win as CPU can already start computing the next frame. Turning nasty bit ON causes very considerable performance drop - with it CPU no longer has that head start on next frame. ------------------ Dread runs better with Fast RAM. Reference 1. https://twitter.com/KK_DMA/status/1435530604372705280?s=20&t=zne3zkrRyr-28u-x44ZJlw

This has nothing to do with my post, which talks about planar vs packed/chunky graphics.

Anyway, from you link:

The game is currently CPU bound.

@cdimauro

Quote:

This has nothing to do with my post, which talks about planar vs packed/chunky graphics.

Dread is one of the best practical examples for planar with Bilter accelerated C2P on stock A500 with 1 MB Ram.


Quote:

The game is currently CPU bound.

That's a given for 68000 @ 7.1 Mhz.

Dread's frame rate is pretty smooth on the stock A1200 (cache disabled).

Dread's frame rate is smooth on A1200//TF1260 (cache disabled) and A500/PiStorm-Emu68 (fast cache disabled).

PiStorm-Emu68's control settings can reduce performance to approximate various 68040 clock speeds e.g. Progressive Peripherals & Software 040 accelerator for A500.

Dread failed on A500/Wicher 508i (68HC000-20 @ 25 Mhz and 50 Mhz) with full-screen graphics corruption. Worked fine with Wing Commander OCS/ECS. Wicher 508i @ 50 Mhz is slightly slower than my old Amiga 3000's 68030 @ 25 Mhz.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: This has nothing to do with my post, which talks about planar vs packed/chunky graphics. Dread is one of the best practical examples for planar with Bilter accelerated C2P on stock A500 with 1 MB Ram.

Fine but, as I've already said, this is nothing to do with the packed vs planar graphics discussion.

@cdimauro

Quote:

Maths is enough.

FTFY.

On a serious note. That’s all well and good, but how is anyone able to appreciate your genius if you don’t put something in their hands to play with?

@Bosanac

Quote:

if you don’t put something in their hands to play with?

Calling Finbarr Saunders! Calling Finbarr Saunders!

At least you didn't include the words "firm" or "solid".

_________________
Doing stupid things for fun...

@cdimauro

Quote:

cdimauro wrote: My article about planar vs packed graphics is finally published: Il falso mito dei bitplane più efficienti (della grafica packed/chunky) I suggest you to translate it with deepl.com if you want a more accurate version or use Google Translate to keep the formatting (unfortunately deepl.com doesn't give this useful option). Enjoy!

For those interested in translation

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@Bosanac

Quote:

Bosanac wrote: @cdimauro Quote: Maths is enough. FTFY. On a serious note. That’s all well and good, but how is anyone able to appreciate your genius if you don’t put something in their hands to play with?

I can still live...


@pixie

Quote:

pixie wrote: @cdimauro Quote: cdimauro wrote: My article about planar vs packed graphics is finally published: Il falso mito dei bitplane più efficienti (della grafica packed/chunky) I suggest you to translate it with deepl.com if you want a more accurate version or use Google Translate to keep the formatting (unfortunately deepl.com doesn't give this useful option). Enjoy! For those interested in translation

Thanks!

@cdimauro

Quote:

cdimauro wrote: @Hammer Fine but, as I've already said, this is nothing to do with the packed vs planar graphics discussion.

Practical demonstration trumps theory.

Last edited by Hammer on 30-Oct-2022 at 12:22 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@cdimauro

An article that is your own opinion and that again is only words without at least a real proof of concept.

If you can' t provide a proof of concept, you are by definition an opinionist, articolist, newsagent ("giornalaio" in Italian).

Waiting for the proof of concept and implementation details or else it didn' t happen.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: @Hammer Fine but, as I've already said, this is nothing to do with the packed vs planar graphics discussion. Practical demonstration trumps theory.

Demonstration of what?


@Massi

Quote:

Massi wrote: @cdimauro An article that is your own opinion and that again is only words

It's evident that you haven't read the article.

In fact, there aren't just word, but there are demonstrations with maths and numbers that prove them.
Quote:

without at least a real proof of concept If you can' t provide a proof of concept, you are by definition an opinionist, articolist, newsagent ("giornalaio" in Italian). Waiting for the proof of concept and implementation details or else it didn' t happen.

PoC is for people which don't understand maths.

Not my problem.

CDIPADDING

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