@fishy_fis

Quote:

fishy_fis wrote: Quote: thread which was maliciously spammed by the usual troll and was mostly off topic anyway. Oh my. Possibly the singularly most palpably ironic thing Ive ever seen. Do you have *any* sense of self awareness? Are you even aware of the concept?

Friend Fishy,
do you have any awareness?

I mean, you are talking to Matthey, how can you hope for a meaningful acknowledgement of any sort?
Best case he will give you the usual pile of numbers, fingers frantically bashing an old stained keyboard in a grease soaked barn somewhere in rural America, faint dreams of being a sought after scientist dissolving in the dusk.

/M!

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

Quote:

MEGA_RJ_MICAL wrote: PA🛞🛞ING

It's to stop you hurting yourself.

@MEGA_RJ_MICAL

Pot... kettle... black... much?

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

@matthey

Quote:

matthey wrote: cdimauro Quote: A 486 is quite standard and should be parte of the ASIC (since it requires around 1 million transistors). I was using the existing MiSTer 486 core as an example of CPU sizes relative to the limits of the FPGA size rather than suggesting a 486 core should be included. A 68040 core would also be difficult to fit with enough room for chipset simulation. A 486SX or 68040V without FPU may fit better but many retro customers want performance, features and compatibility and MiSTer can only deliver on 2 out of 3. With an ASIC 68k SoC, DOSBox could be used with better than 486 performance.

Are you now advocating emulation over an ASIC implementation?
Quote:

While adding x86, MIPS, SuperH, PPC etc. cores may be popular for retro hardware, it would make the SoC more specialized for retro use.

But that was exactly the case in this discussion. Isn't it?
Quote:

Many CPU cores from about 2000 on were highly customized so one MIPS CPU core for the PS1, PS2 and N64 or one PPC core for the PS3, Xbox 360, Wii and Wii U would be difficult as well as GPU differences.

There should certainly be a stop / red line which marks the end of the retrogaming age.
To me it'd be reasonable 20 years ago, because patents are already expired and a reimplementation of the same devices is feasible (besides embedding IP, which falls under the copyright law -> it's too long to expire -> no IP content should be embedded). So, everything below 2004 should be ok.
Quote:

An early x86 core may be easier and if the MiSTer 486 core is in good shape and free to use, it is tempting to include but probably not worth it as there are plenty of old PCs and DOSBox on modern x86-64 hardware can emulate x86 efficiently.

Regarding emulation see above. But at least the more mainstream x86 cores could be embedded.

Since ASICs can fit hundreds of billions transistors, I don't a problem by embedding most of the retro cores (CPUs and GPUs) on a single chip. The cost for the ASIC should still be quite low, while allowing to reproduce almost every retroplatform of the past.
Quote:

cdimauro Quote: Why the 68060 needed a big (and slow, IMO) 16-bit LUT to decode its (main) opcode? If the architecture was clean then you would have needed only some logic circuits to decode & break down the main opcode to the simpler, internal macro-ops. The reality is the big LUT and not the small logic circuits. And the reality is that the 68060 was difficult to scale-up with the frequency, even on better/newer processes and with overclocking. Maybe a 16-bit LUT is fast and cheap. How many transistors would a 16-bit LUT use with CMOS? Google AI Overview Quote: A 16-bit Look-Up Table (LUT)—which is a 4-input, 1-output logic block—uses approximately 128 to 150 transistors in standard static CMOS. The Transistor Breakdown o Memory Elements (96 - 100 transistors): The truth table requires 16 bits of storage. Standard SRAM cells use 6 transistors each:16 bits × 6 transistors = 96 transistors. (Some configurations also use a pair of inverters per bit for local buffering, which can push this number up slightly). o Multiplexer Tree (32 - 48 transistors): A 16-to-1 multiplexer routes the correct memory bit to the output. In CMOS, this is typically constructed using transmission gates. A standard transmission-gate MUX uses about 2 to 3 transistors per equivalent 2-to-1 MUX. Some things that are expensive in traditional programming languages are cheap on silicon. HDL code may look like existing languages and some of the logic still applies but some things are much different.

Right, but I was mentioning a different LUT.

To completely remove all exceptions in the opcodes in "one shot" and getting a "clean" (internal) opcode, then a 16 -> 1 LUT is required to generate a bit which signals if the opcode/instruction is normal (can be decoded with regular patterns) or special (an exception that should be handled separately).
Such a big LUT requires around 400K transistors, according to the data that you've shared. Plus the the logic to decode the regular patterns.

This example shows why decoding x86 instructions is much cheaper using LUTs: a single 8 -> 1 LUT (to catch the regular prefixes, for example) requires less than 1,600 transistors.
Quote:

cdimauro Quote: As I've said before, this can be verified implementing a similar 68k, x86, PowerPC, MIPS, whatever cores on the same FPGA with similar features (2-ways in order, same L1 caches, same TLBs, etc.) and checking how high they can with the frequency. It'd be a fair comparison, since the only change is the intrinsic core, leaving everything else the same. There would still be different levels of optimization between CPU cores with different architectures. One of the remaining advantages of x86(-64) cores is that they were highly optimized with many incremental improvements over time which were reused in newer Intel and AMD designs. Sometimes acquired CPU designs and architect knowledge are incorporated too including for the 68k with the 68060 design and team coming from outside Motorola/Freescale. The CISC 68k often gets classified with the CISC x86 but they are more different than most RISC cores and require much different solutions to problems. It would be valuable to continue 68k development using the experience and design worked on by two 68k development teams.

But that's another thing. In this context the idea was to just compare the cores of architectures using exactly the same hardware elements, with the sole exception of the specific core. The core can and should be implemented as best/optimized as it's possible.

With that you can evaluate the maximum frequency reachable by each core, and draw proper conclusions about the scalability of the architecture.

It's really simple.
Quote:

cdimauro Quote: No, it was because the mobile market was monopolized by ARM and JIT translating ARM binaries to x64 wasn't efficient (required much more power -> less battery available). So, the platform wasn't overall competitive with the ones which were natively running ARM core. The Intel platform could have been competitive only when all Android applications (especially games) would have been natively available. Which was far away the case, unfortunately. ARM accepted lower margins in mobile and embedded markets than Intel in workstation/server and desktop markets. Businesses generally try to decrease less profitable business while increasing more profitable business. It is also expensive to enter new markets and take market share which usually requires undercutting competitor prices and/or spending more money on marketing. While I believe Intel Atom cores were competitive in the mobile market, the cores were larger than the ARM competition at the time which increased the price.

That's questionable. Such SoCs integrated a lot of code/data caches, and several uncore elements, which roughly put them on par.
Quote:

Android executes Dalvik bytecode not native ARM code. There should be a minimal disadvantage to switching from ARM to another architecture if the sources are available for the virtual machine.

That wasn't the problem, in fact. The real problem was represented by the native applications, written in C++ and using the NDK (Native Development Kit), which were only compiled for ARM by the software houses. Games, particularly.

Even if Houdini (Intel's internal ARM->x64 JIT compiler) was doing a good work, it wasn't enough for competing due to overall lower performance and the major power consumption which drained too much battery compared to the ARM SoCs. And on top of that, you also have to factor some incompatibilities.

Only a few software houses supported Intel providing ports or compiled binaries for its architecture, and at the end this determined the impossibility for the company to continue competing.
Quote:

cdimauro Quote: ARM was CISC since day one (it was also fully microcoded). AArch64 is more similar to MIPS/Alpha, but ARM was smart enough to borrow some complex addressing modes from the original ARM32 architecture, and add many more complex instructions to better address real-world use cases. I would not call ARM1 "fully microcoded" but more like partially or minimally microcoded. Reverse engineering the ARM1 processor's microinstructions https://www.righto.com/2016/02/reverse-engineering-arm1-processors.html Quote: So is the ARM1 microcoded or not? The instruction decoder is clearly made up of microinstructions executed sequentially or with branching. It makes sense to look at this as microcode. But on the other hand, the microcode is fairly simple and forms a small part of the total control circuitry. A large amount of hardcoded logic interprets the microinstruction outputs to generate the control signals. My conclusion is the ARM1 should be called "partially microcoded" or maybe "hybrid microcode / hardwired control".

I beg to differ. All instructions are translated into microop and executed via a sequencer: to me it's enough to call it fully microcoded.
Quote:

As I have stated before, I believe David Patterson provided RISC guide lines rather than immutable laws. If there was an immutable law, a "reduced instruction set" would be a good candidate as it is in the name but the 68k has a smaller instruction set than every load/store architecture I can think of today.

In fact, there wasn't a single guideline to fullfil. Patterson clearly defined a RISC a processor for which all those four rules apply:
- a small number of instructions;
- memory access only via load/store instructions;
- fixed-length opcodes;
- instructions should be simple, being executed mostly in one clock cycle.

If one of those rules don't apply, then it's not a RISC. Rather, it's a CISC.

Those guidelines could be satisfied by very early RISC designs, but certainly not already after a few years.

Trying to stretch the definition by softening or even completely suppressing one or more of those guidelines leads to something which can't be called anymore "RISC".

For this reason I prefer to use LD/ST (as Mitch suggested) as a better term, instead of RISC. That's because what's roughly is left out of this paradigm, since all other pillars are gone (well, AArch64 isn't LD/ST anymore, due to the memcpy instructions).
Quote:

RISC-V tries to get away with remaining RISC by making the base instruction set reduced but then the majority of RISC-V cores using the many extensions and instructions would not be RISC. ARM1 only had 45 instructions compared to the 56 instructions of the 68000. ARM1 was a reduced instruction set load/store GP register architecture. Besides some microcoding, more and more powerful addressing modes were used including index with shifted scale, which could be used on many non load/store instructions as well. The architects made the not so simple decision to add a barrel shifter to the ALU so decided to make best use of it. The CISC like addressing modes are useful and a good decision while allowing shift in many instructions although some instructions no longer had single cycle throughput. ARM would add multi-cycle MUL instructions in ARM2 and if having multi-cycle throughput instructions was no longer RISC then RISC died in the 1980s.

That's exactly the point, and not only because of the multicycles instructions (which were partially tolerated. Obviously, because you can't have load instructions executed in just one cycle. By definition).
Quote:

HP was smart to put RISC in the name so there would be no question they remained RISC with PA-RISC despite how may instructions they added and despite also supporting scaled index registers and base register update, another ARM addressing mode feature. The classic RISC pipeline used 2 reg read and 1 reg write ports to the register file which an update breaks while being quite useful again. The 68k also uses this for post increment and pre decrement addressing modes and could easily add it generally with a free bit in the full extension word format as the HP research found it useful.

That's good to have for supporting stride accesses (base reg updated with a fixed offset after each memory access) to arrays of structures.

Unit-stride is already built-in, thanks to pre-decrement/post-increment addressing modes.
Quote:

The other weird thing about ARM1 was the conditional execution of instructions using predication which was useful but not worth the encoding space

Why? There was plenty of encoding space due to the max 16 registers available in the ISA. If you take those 4 prediction bits and consider a binary (3-operands) instruction, you need 4 + 3 x 4 = 16-bit for that, leaving the remaining 16-bit for the opcode and much more. That's the reason why the barrel shifter is used here: there was enough free space to allow instructions to specify a shift amount and the shift/rotation type for the most important instructions.

Something which wasn't feasible anymore with AArch64, since it has 32 registers, which take 15-bit only for them, leaving not so much space for the opcode and other things (including a 64-bit Thumb-2 variant).
Quote:

and limits designs to requiring support for predication.

Indeed, but Mitch has first-class support for predication on its My 66000 ISA. I assume that it doesn't costs so much to implement. Whereas the benefits are very relevant, especially with modern micro-architectures which have very long and wide pipelines, for which a branch misprediction means even hundreds of instructions thrown out and many cycles wasted before the first instruction retires again.

Early in my new architecture I supported only a mechanism like Thumb-2's IT instruction, but a bit more general. However, and thanks to my experience with Mitch and his team, some time ago I've allocated a full "octant" (1 configuration out of "topmost" 8 bits in the main opcode) with plenty of predication instructions, which gives way more flexibility for this useful mechanism.
Quote:

Despite some less than simple design decisions, ARM2 used only ~30,000 transistors. They saved transistors using simplifications like only having 14 GP registers with code density similar to 32 GP register RISC ISAs and combining the PC with flags in a register for faster interrupts even though this limited future addressing space. Some simplifications are just plain mistakes with or without RISC. Calling ARM1 CISC does not seem fitting but maybe a hybrid leaning more toward RISC is appropriate.

Well, you forgot the super complicated instructions which even ARM1 had (and which now are, more or less, part of an embedded extension for RISC-V).
Quote:

cdimauro Quote: It's difficult to change the ISA when now have a billions market. Changing the ISA is not a deal breaker for the embedded market. With the RISC-V VisionFive 2 SBC, you compile your own software and recompile your kernel as needed after installing new drivers. Actually, this is sometimes required with RPi SBCs and A1222 software too. Raspberry Pi 500+: NOW we're gaming! (Jeff wears an "It has been 0 days since I recompiled the Linux kernel" t-shirt and has to recompile his RPi 500+ kernel in the video) https://www.youtube.com/watch?v=Dv3RRAx7G6E But you can't do it with all available software. RISC-V aims for binary compatibility within its ecosystems (besides the big mistakes that they made, which brought to binary-incompatibility for some extensions), and with 25% of the embedded market now (AFAIR 65 billion RISC-V cores were sold 'til recently) another, incompatible, ISA is unlikely to come. Quote: In contrast, there are plenty of 68k hardware users who never compiled a program in their life, maybe the majority. Cheap small footprint hardware used to be more standard and easier to use. Is RISC-V or ARM good enough or was Jay Miner right to insist on having the 68k and remains the future we were promised? Well, there was no ARM neither RISC-V at the time, so the answer is obvious. It was Motorola that killed a bright future for the 68k architecture, unfortunately. Quote: https://www.reddit.com/r/RISCV/comments/1loskj7/picture_this_a_new_official_commodore_computer/ [quote] But they also want to make new, modern, products. The focus on "digital minimalism" and creating products that are "not just retro but also the future", aims to recapture this optimistic spirit while also innovating with new hardware and software. Historically, Commodore used the 6502 and 68000 CPUs. Had they survived a bit longer they might well have gone into either ARM (yay!) or IBM compatability (boo) ... but making a new start today, wouldn't RISC-V make more sense for them? It could also be a huge huge thing for RISC-V, if it happened. They apparently do have one or more new products in development, but we don't have any clues what they are. The post is from Bruce Holt who is one of the more knowledgeable RISC-V supporters. Is simple non-standard RISC-V and bloated unfriendly Linux the future purgatory we were promised?

It is, as we've already observed. RISC-V is already a fragmented ecosystem with a complete mess of extensions.

Just take a look at the current proposals for the so called matrix extensions (required by the LLM mantra/trend):
https://www.realworldtech.com/forum/?threadid=228054&curpostid=228054
The last proposal is a manual of more than 300 pages, with wagons of new instructions and a complete set of (independent) registers!

I don't want to say that competitors (Intel, ARM) are better, but at least they have already ratified & stabilized extensions, so they are ready to the market with products, whereas the academics are still losing time thinking on a market which has very rapid evolutions (read: you can't wait for a fully "upfront" design before releasing a proper extension, because you're missing the market!).