Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Newsgroups: comp.arch Subject: Re: Whether something is RISC or not (Re: PDP-8 theology, not Concertina II Progress) Date: Fri, 12 Jan 2024 13:55:02 GMT Organization: Institut fuer Computersprachen, Technische Universitaet Wien Lines: 179 Message-ID: <2024Jan12.145502@mips.complang.tuwien.ac.at> References: <868r55parv.fsf@linuxsc.com> <2024Jan11.080258@mips.complang.tuwien.ac.at> <2024Jan12.102148@mips.complang.tuwien.ac.at> Injection-Info: dont-email.me; posting-host="0a1b8fb2e64f98d4494010975df925a8"; logging-data="3655600"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/V3PzxH5jKqurgludXmlFm" Cancel-Lock: sha1:MGFBnk7bm9Nly358QHgu2KDPjhg= X-newsreader: xrn 10.11 Bytes: 10462 This is a reposting of <2024Jan12.102148@mips.complang.tuwien.ac.at> with some corrections: I added Alpha, and made IA-64 corrections. anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >It would be interesting to take John Masheys criteria and evaluate a >few more recent architectures: Alpha, IA-64, AMD64, ARM A64, RV64GC. >I'll put that on my ToDo list. Ok, let's see. Taking his criteria from . It is worth reading the posting in full (in particular, he explains why certain features are not in RISC architectures), but here I cite the parts that are the criteria he listed. |MOST RISCs: | | 3. | a. Have 1 size of instruction in an instruction stream | b. And that size is 4 bytes | c. Have a handful (1-4) addressing modes) (* it is VERY hard to count | these things; will discuss later). | d. Have NO indirect addressing in any form (i.e., where you need one | memory access to get the address of another operand in memory) | 4. | a. Have NO operations that combine load/store with arithmetic, i.e., | like add from memory, or add to memory. (note: this means | especially avoiding operations that use the value of a load as | input to an ALU operation, especially when that operation can | cause an exception. Loads/stores with address modification can | often be OK as they don't have some of the bad effects) | b. Have no more than 1 memory-addressed operand per instruction | 5. | a. Do NOT support arbitrary alignment of data for loads/stores | b. Use an MMU for a data address no more than once per instruction | c. Have >=5 bits per integer register specifier | d. Have >= 4 bits per FP register specifier [...] |So, here's a table: | | * C: number of years since first implementation sold in this family (or | first thing which with this is binary compatible). Note: this table was | first done in 1991, so year = 1991-(age in table). | * 3a: # instruction sizes | * 3b: maximum instruction size in bytes | * 3c: number of distinct addressing modes for accessing data (not jumps) | I didn't count register orliteral, but only ones that referenced | memory, and I counted different formats with different offset sizes | separately. This was hard work ... Also, even when a machine had | different modes for register-relative and PC_relative addressing, I | counted them only once. | * 3d: indirect addressing (0 - no, 1 - yes) | * 4a: load/store combined with arithmetic (0 - no, 1 - yes) | * 4b: maximum number of memory operands | * 5a: unaligned addressing of memory references allowed in load/store, | without specific instructions ( 0 - no never [MIPS, SPARC, etc], 1 - | sometimes [as in RS/6000], 2 - just about any time) | * 5b: maximum number of MMU uses for data operands in an instruction | * 6a: number of bits for integer register specifier | * 6b:number of bits for 64-bit or more FP register specifier, distinct | from integer registers [...] |So, here's a table of 12 implementations of various architectures, one per |architecture, with the attributes above. [...] I'm |going to draw a line between H1 and L4 (obviously, the RISC-CISC Line), and |also, at the head of each column, I'm going to put a rule, which, in that |column, most of the RISCs obey. Any RISC that does not obey it is marked |with a +; any CISC that DOES obey it is marked with a *. So ... .... here's the table, with the entries vor Clipper, i960KB and CDC6600 inserted and that for the additional instruction sets appended (starting with ARM1): CPU Age 3a 3b 3c 3d 4a4b 5a 5b 6a 6b# ODD (1991) RULE <6 =1 =4 <5 =0 =0=1 <2 =1 >4 >3 A1 4 1 4 1 0 0 1 0 1 8 3+ 1 AMD 29K B1 5 1 4 1 0 0 1 0 1 5 4 - MIPS R2000 C1 2 1 4 2 0 0 1 0 1 5 4 - SPARC V7 D1 2 1 4 3 0 0 1 0 1 5 0+ 1 MC88000 RISC E1 5 1 410+ 0 0 1 0 1 5 4 1 HP PA F1 5 2+ 4 1 0 0 1 0 1 4+ 3+ 3 IBM RT/PC G1 1 1 4 4 0 0 1 1 1 5 5 - IBM RS/6000 H1 2 1 4 4 0 0 1 0 1 5 4 - Intel i860 J1 5 4+ 8+ 9+ 0 0 1 0 2 4+ 3+ 5 Clipper K1 3 2+ 8+ 9+ 0 0 1 2+ - 5 3+ 5 Intel 960KB Q1 27+ 2+ 4 1 0 0 1 0 1 3+ 3+ 4 CDC 6600 L4 26 4 8 2* 0* 1 2 2 4 4 2 2 IBM3090 M2 12 12 12 15 0* 1 2 2 4 3 3 1 Intel i486 N1 10 21 21 23 1 1 2 2 4 3 3 - NSC 32016 CISC O3 11 11 22 44 1 1 2 2 8 4 3 - MC 68040 P3 13 56 56 22 1 1 6 2 24 4 0 - VAX 6+ 1 4 7+ 0 0 1 0 1 4+ - 3/8 ARM1 -1 1 4 1 0 0 1 0 1 5 5 0/11 Alpha -10 2+ 10+1 0 0 1 0 1 7 7 2/9 IA-64 -12 2+ 4 7+ 0 0 1 1 2+ 4+ 5 4/7 ARMv7 T32 -12 15+15+7+ 0 1+ 2+ 1 4+ 4+ 4 7/4 AMD64 -22 1 4 15+ 0 0 1 1 2+ 5 5 2/9 ARM A64 -28 2+ 4 1 0 0 1 1 2+ 5 5 2/9 RV64GC Notes: I did not want to pre-classify the architectures, but used + for all the criteria that Mashey considered non-RISC (and consequently nothing rather than * for those that he considered RISC). The ODD column contains two values, first the number of criteria according to which the architecture is non-RISC, then the criteria according to which the architecture is RISC. CDC6600: there are some mistakes in entry that I fixed, and I also added +s to those cases that did not satisfy Mashey's RISC criteria. I classified 30-bit instructions as 4-byte instructions. I used Mashey's entry for 5b. Apparently you could buy some ARM1 in 1985 as an add-on board, but the wide release came with ARM2 in 1987. I used the 1985 date; Anyway, the Age criterion is just ageism. IA-64: There are instructions that occupy 2/3 of a bundle, while most occupy 1/3, so I counted two instruction sizes. Specifying the maximum instruction size is interesting (how do you count the 5 extra bits in a bundle?), but in any case, IA-64 does not satisfy 3b. In ARMv7 T32 is required, and the M profile only includes T32. Alignment always works for some loads, and never for others, resulting in 2 MMU accesses being required for some memory accesses. But the same has been true for PowerPC long before ARMv6 required unaligned accesses to work. There is VFP[345]-D16 with only 16 FP registers on some implementations, but that would also satisfy 6b; most use 32 64-bit FP registers. AMD64 can have instructions up to 15 bytes (with prefixes and all). All addressing modes with displacement are counted twice according to Mashey's rule, RIP-relative is not counted extra. The MOVS instruction has two memory operands; I did not count REP MOVS/STOS etc. as separate, although they arguably are; anyway, AMD64 is non-RISC according to 4b. SSE2 instructions require alignment; that blunder was fixed in AVX, but base AMD64 only has SSE2. ARM A64: I used the availability data of the iPhone 5s in 2013 for Age. A64 has not only interesting offset options, but also addressing modes that sign/zero-extend the index operand; how to count them? In any case, A64 does not satisfy 3c. I counted the one memory operand of a load/store-pair instruction as one memory operand. There are a very few cases where unaligned accesses produce an alignment fault, so I gave 1 for 5a. As usual, unaligned accesses may cause two MMU uses. It's hard to get a date for RISC-V, with things like the Rocket in 2016, but the document with the ratified architecture parts of RV64GC only available in 2019; so I used the latter year for the age. 5a: atomics are required to be aligned; everything else may be unaligned. So, looking at the table, ARM1, ARMv7 T32, ARM A64, and RV64GC are more RISC than non-RISC according to these criteria, and AMD64 is more non-RISC than RISC, which is exactly what I would have said without this table. So Mashey's criteria still seem to be mostly valid 32 years later. However, I would not classify the CDC6600 as RISC, because it does not have general-purpose registers. It can be seen as a precursor, though, and the fact that it shares many of the RISC criteria shows that despite changing technology, when you want to design an architecture for performance, the architectural features you design in and especially those that you don't design in have stayed similar across 59 years. Some criteria, though, despite making implementation difficult, have been designed into relatively recent architectures despite being classified as non-RISC by Mashey; in particular, allowing unaligned accesses has won; and consequently, they all require up to 2 MMU uses per instruction for data operands. - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup,