Project Logs

Collapse

• Sort your instruction fields and opcodes !

  Yann Guidon / YGDES • 10/07/2026 at 20:53 • 2 comments

  I am looking at you, RISC-V. The x86 hatefest has flown and crashed decades ago already but look who's trying to outdo Intel ?

  My complaints have been eloquently vindicated by Dmitry at RISC-V: They Should Have Known Better

  This is also a follow-up to the corollary post 23. Get your operands as fast as possible.

  I hear "But the compiler handles all the MUX to get the operands" which is the typical tonedeaf mentality of the RISC-V cult.

  The RISC-V "specification" totally burns the lessons and examples of the MIPS R2000 and R3000 which were not perfect but coherent enough to be taught in universities and at least tried to homogenise the instructions fields.

  Tried.

  There is a first level of general organisation, a clear intent and hints at some methodology (who reads Patterson & Hennessy's books anywa ?) and then the beautiful wishful thinking crumbles as soon as someone needs an extension. MIPS held because it had coprocessor interfaces. RISC-V ditched them.

  Nobody tries coherence anymore: a spec is dropped from the Swiss cartel and now you have a huge bit shuffler that adds 10 gates to the operand fetch's critical datapath. It's so beyond ridiculous at that level, that it's not funny anymore, and they dare mock the x86 insanity.

  For the #YASEP, I admit that the instruction coding became quite crowded and I wish I can reorganise the opcode map and modes. That's one reason why I have moved on and a streamlined pure-mode YASEP32 would be awesome. But at no point in time did it need to get information from all over the instruction fields. 

  For #YGREC8, you have an immediate understanding of the architecture by looking at ONE global map of the opcode and instructions. 2 more pictures complete the description and you can already write an assembler/disassembler. I have spent time rearranging the map according to several constraints, but you'll always find a given bit at a fixed place.

  Decoding is SIMPLE, as immediate as possible and leads to a straight-forward decoding decision tree:

  That's it ! And I'm sure Seymour Cray could find a detail somewhere to streamline.

  Now, Dmitry took it upon himself to compile these tables:

  Where immediates come from in 32-bit instructions
  Format	31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
  J-type	20	10	9	8	7	6	5	4	3	2	1	11	19	18	17	16	15	14	13	12
  U-type	31	30	29	28	27	26	25	24	23	22	21	20	19	18	17	16	15	14	13	12
  I-type	11	10	9	8	7	6	5	4	3	2	1	0
  S-type	11	10	9	8	7	6	5														4	3	2	1	0
  B-type	12	10	9	8	7	6	5														4	3	2	1	11

  Where immediates come from in 16-bit instructions
  Instr	15	14	13	12	11	10	9	8	7	6	5	4	3	2	1	0
  C.LWSP				5						4	3	2	7	6
  C.SWSP				5	4	3	2	7	6
  C.LW C.SW				5	4	3				2	6
  C.J C.JAL				11	4	9	8	10	6	7	3	2	1	5
  C.BEQZ C.BNEZ				8	4	3				7	8	2	1	5
  C.LUI				17						16	15	14	13	12
  C.ADDI16SP				9						4	6	8	7	5
  C.ADDI4SPN				5	4	9	8	7	6	2	3
  C.LBU C.SB										0	1
  C.LH C.LHU C.SH											1
  C.JT C.JALT							7	6	5	4	3	2	1	0
  all others				5						4	3	2	1	0

  Who found this scheme and thought it was brilliant ? Not a student, this is professional-level malfeasance.

  Please ! Point me to one relevant CPU architecture that was half this messed up (x86 wouldn't even dare do this).

  Fetching the operands must be IMMEDIATE so computation can start immediately. While the register set is being fetched for the SRI operand, other circuits of the YGREC8 speculatively decode the immediate field, which can be IMM8 or sign-extended IMM4. IMM9 is a special case since it's a direct address immediately fed to the IO block, so no MUXing required.

  I can get my SRI operand with a depth of 2 MUXes. RISC-V ? "oh, duh, I don't care, the synthesiser manages it for me" and the decoder becomes a large, mushy cloud of gates that nobody takes responsibility for.

  RISC-V is the first mainstream architecture that stopped trying as soon as it got momentum.

  Get your fields together damnit !

  That's the result of not having to pay each gate a dollar each, instead delegating the critical decisions to the synthesiser and the compiler people.

  It is also the price of wanting one architecture to do everything: it does everything "good enough"... (segue to another post)

• For ASIC, use latches and R/S FF whenever possible

  Yann Guidon / YGDES • 10/06/2026 at 12:22 • 0 comments

  Sadly, DFF (the normal gate that samples the input data when the clock rises) are silicon hogs. It will depend on your PDK and SCL of course but one DFF is two transparent latches (unless you use the Earle topology, which has been abandoned).

  These DFF gates are essential and need to be used all over the place but many circuits do not require them, yet your HDL coding habits will lure you into implementing more and more. For example certain control/configuration registers, IO ports, and even the register set can be shrunk (which also draws less static power and saves silicon real estate)

  Of course if you play with FPGA, the DFF are "free" and this won't make a difference, until you port to ASIC and your floorplan with explode: what was free now costs 4× or 6× more than a normal boolean gate.

  4-phase clocking can be used for long pipelines (multipliers ?), if the circuit can be cut into 4 equal-time slices.

  And this applies to "standard CMOS", as Domino logic rewrites all the rules (but you're unlikely to encounter this unless you work for the biggest companies)

• Emit Is Commit

  Yann Guidon / YGDES • 10/04/2026 at 22:29 • 17 comments

  Let's start with a little reminder of the instruction lifecycle.

  • Decode is when the instruction has been fetched and selected, stored in an instruction buffer or similar, and the fields are broken apart to decide what to do.
  • Emit is quite synonymous with Issue. It is when the instruction's parameters enter the execution pipeline to start the read op / operate / writeback dance.
  • Commit is when it is decided that there is no "going back", the instruction will keep its slot in the pipeline and will not be cancelled (think delayed slots or conditional moves as some examples).
  • Retirement is specific to Out-of-Order CPU core : the in-flight instructions are retired from the reordering buffer to restore program order and update the instruction pointer. It does not contribute to the operation but preserves control flow consistency. This is equivalent to commit, but pushed beyond the execution pipeline.

  The semi-radical and first F-CPU architecture called FC0 used a principle borrowed from common sense and the CDC6600, called "Out Of Order Completion" : instructions are emitted and executed in order but since some take longer than others, they can writeback to registers in a different order than during decode. Other instructions can be scheduled by the programmer/compiler to use other resources until the late result becomes available. It usually requires a "scoreboard" that (if done correctly) uses much fewer resources than classic OOO. The performance is less aggressive though and depends on smart scheduling of the instructions. Which is a fair compromise for any RISC endeavour.

  Of course, memory accesses can stall, trap and who knows what, so FC0 introduced weird load/store instructions that then became the fully architecture-visible address registers of the later YASEP and beyond. These "split" instructions decouple the memory units and shield the main blocks of the CPU (decode, execution and memory) from each other. This fits very well with OOOC.

  To design the FC0's ISA, it has been decided that a decoded/emitted instruction can not be rewound back or cancelled/bubbled. This would create a nightmare of register renaming, issuing and retiring that might bring 20% of performance but increase the size by 100% at least, and testing/validation become worse.

  Then there is the SPECTRE class of attacks that play on prefetchers, speculative execution and other dynamic states. FC0 came long before this was a major recognised threat, but the DEC people had already spotted the danger when designing the OOO Alpha 21264.

  Furthermore, typical OOO cores require branch prediction because the pipeline depth is seriously increased, sometimes ridiculously so : an ALU operation would be one cycle among 7,10 or 13-cycle deep pipeline. For the same size you get two in-order-emit cores and twice the branch decision throughput without the hassles of a huge branch history table, you can even multithread/multiplex the threads.

  All in all, if you want to have the best ever performance for a single thread, you'll pay the price in pure cost, surface, complexity, vulnerability... Of course this also shields the programs from whatever architectural idiosynchrasies and OOO cores can vary in any way possible with little loss of performance.

  But if you want to KISS, stick to "Emit is Commit" : any instruction that enters the execution pipeline (operand read, operation, writeback) is valid and will complete with no chance of trap. This forces the ISA to make all instructions conditional to their execution being legal, and the operands to be ready: a scoreboard does that. FC0 also keeps hidden flags to tell the decoder that a read from memory to a register is complete, so the instruction decoder may stall.

  This simplifies trap handling and pipeline flushes considerably since there is no specific pipeline flush mechanism, and the pipeline can remain shallow, which highly reduces the need for a branch predictor.

  I think the "original...

  Read more »

• Let the hardware do what it does best.

  Yann Guidon / YGDES • 12/20/2023 at 01:35 • 0 comments

  The title says it all but a deeper explanation will shine more light on it.

  This is another point where I diverge from the Patterson & Hennessy canon, which emphasises the study of real-life code to see which opcodes are the most used. This was a major argument in the 80s when the RISC vs CISC debate raged, and we should not forget that at this time, most computers (microprocessor-based or not) were microprogrammed (let's exclude Cray's designs of course).

  Reducing the instruction set complexity also reduces the weight of the microprogram, which has almost vanished by Y2K (if you forget the x86 of course). So today, when you create your own ISA, you look at the "Quantitative Approach"'s figures and should ask yourself :

  • Does this apply to me ?
  • Is it my relevant to my application or domain ?
  • What is the effect of the compiler ?
  • Haven't times changed since ?

  P&H's RISC works (and their predecessors) have a very good point against microcode, which has been cemented during the last 40 years. But this argument has sometimes been taken to the extreme, creating weird feedback loops.

  Let's take C: it was designed on a PDP-7 then PDP-11 and inherited some features of these platforms. In particular the absence of rotation operator. And there are only the AND/OR/XOR/NOT operators. So what did the RISC people do ? They found that none of their benchmarks (written in "portable" C) would include rotation or combined boolean operations. So the SPARC and MIPS didn't have one.

  My point is : if you already have a barrel shifter, you can do rotation with a small additional work. The counter-argument is "it will slow down the whole pipeline for an operation that is barely used and can be emulated with 3 instructions" (if not 4). Now, when the codepath reaches the point where rotation is important, these 3 opcodes slow the tight loop down, increase the time and energy to move data around (in and out of the register set etc.) as well as the register pressure (to name a few).

  OK maybe that was not the perfect example, let's look at the boolean operations: there is a whole world beyond AND, OR and XOR. Particularly if they are integrated in the ALU where the adder needs one operand to be inverted to perform SUB. This inverter (alread covered in other logs) can be reused to perform ANDN, ORN and XORN. A bit more fiddling gets you NAND and NOR, for almost no real penalty in clock frequency. And yet these are not implemented.

  Intel brought ANDN with the Pentium MMX and the full ROP3 set in the latest Core generations so there is some merit to it right ?

  But the common languages (and C at their roots) does not provide these operators, which must be inferred by the compiler, leading to the underuse of these opcodes.

  These are only 2 examples but more exist. Thus

  When an operation provides more options for marginal overhead, expose them at the opcode level. Languages and compilers may ignore them but when you need them, you'll be happy. This is why I provide ANDN with the YGREC8 and the whole ROP2 in the YASEP. The cost of these "extra features" is anecdotal and the times it will save your a$$ will be less remembered than when you miss them.

  Because remember: it's a different case than the one against microcode. And don't let others tell you what you don't need.
  

• Use two separate stacks for data and control flow

  Yann Guidon / YGDES • 01/11/2023 at 23:11 • 11 comments

  (to be expanded later)

  This is not just so it could run FORTH almost natively.

  This is a HUGE safety and security feature.

  Plus it also helps performance by separating accesses to different memory regions, while restricting access to the control flow structure (reducing the attack surface).

  The call stack should be almost inaccessible to the lay program.

  More than one data stack is welcome but not necessary. And another type of stack would be for error handling.
  

  The data stacks should grow "up".

  .

  Update: see #POSEVEN 

• Carry and borrow

  Yann Guidon / YGDES • 11/04/2021 at 18:51 • 0 comments

  If there is anything that fueled the RISC vs CISC debates over the decades, it's the status flags, and among them, the carry flag is an even hotter topic.

  This flag has been a common feature of most architectures and MIPS slashed it. Considering that only ASM would support it, it made sense, in a way, because implementing it would not significantly improve the overall performance. After all it's a 32-bit architecture so multi-precision is not required, right ?

  Looking at the shenanigans required to implement multi-precision additions on YGREC8 (5 instructions and 2 branches) and the end-around-carry in C for PEAC (or: "wrestling with GCC's intrinsics and compiler-specific macros"), the carry flag is not a done deal. The POWER architecture implements a sophisticated system to get around hardware limitations but nobody seems to have caught on it.

  There is a big problem as well: the high-level languages. This can't be easily fixed because this side is so deeply entrenched that no solution is in sight. We end up with hand-coded libraries for multi-precision numbers (gmp ?), non-portable macros, weird intrinsics, platform-specific code...

  Platform-wise, there is no easy solution but it is not hopeless.

  Not all architectures need to avoid the carry flag, in particular microcontrollers or cores that will not grow to the point of using out-of-order.
  

  For Y8, the opcode space is so short that I had to ditch the add-with-carry opcode. This is replaced by a 5-opcode macro (10 bytes instead of 2) whenever needed. We'll have to deal with it.
  (update : this and other issues made me add a "prefix" instruction, turning the RISC-like archi into a multicycle core)

  The YASEP has a larger opcode space and includes add-with-carry and sub-with-borrow. This is very classic here.

  The F-CPU however is a totally different beast. Not only can't it have a single carry flag (due to the split pipelines), but because it is an inherent SIMD architecture, several carries would be required. There, the idea is to use a normal register to hold the carry bit(s), using either a 2R1W form or a 2R2W form (ideally).

  • 2R2W is conceptually best except for the need to write 2 values to the register set at the same time. Each partial carry gets its own place in the register in SIMD mode, and there is no bottleneck for the single carry flag at the decoding stage. The single opcode works in a single cycle. FC1 could write the extra data to another cluster.
    Eventually, the opcode could be a two-cycle instruction, first delivering the sum then the carry on the second cycle.
  • 2R1W splits the operation results in 2 separate opcodes, while only one operation is performed. It is slower because 2 successive opcodes are required but it is an easy addition to any existing ISA. On the programming language side, an extra operator "carry" (probably @+ and @- ?) can do the trick.

  There is no perfect solution. Each type of core requires a complex balance so as usual, you're the one who decides (and is to blame).
  
  

• Tagged registers: type

  Yann Guidon / YGDES • 10/19/2021 at 02:36 • 0 comments

  Log 27. Tagged registers talked about "hidden"/"restorable"/"implicit"/caching tags.
  

  There is another type of register tag that is explicit and directly interacts with the ISA, the programs and their state. In this case, the goal is to move the ever-appearing size and SIMD flags of many instructions, to the register set.

  This saves at least 3 bits from every instruction so this is a great win in general-purpose processors like #F-CPU. This is less an issue for YASEP and YGREC8 which only deal with single-size values.
  

  However the side effects easily counter-balance this easy win. Trap behaviour must be clearly defined and consistency checks must be sprinkled all over the system.

  A simple instruction/opcode like ADD then has many behaviours, depending on hidden values : integer or FP ? scalar or SIMD ? what size ?

  The behaviour is not apparent from the opcode alone and we can't know which unit(s) to use at decoding time.

  OTOH tagging the registers could be a "cheap and dirty way" to extend an ISA while reusing opcodes with mixed data.
  

• Privileged instructions

  Yann Guidon / YGDES • 10/19/2021 at 01:48 • 0 comments

  Don't have instructions that can run only in certain "modes".

  I know many CPU do it, even RISC-V, but I can't find a decent reason to accept this.

  • It's a slippery slope : you'll want to do more and more.
  • It's a waste of instruction coding space, which also reduces the overall coding efficiency.
  • It increases the decoder's complexity.
  • What does an instruction do that the Special Registers can't ?

  Remember : Special Registers are where all the configuration, and protection, occurs, so there should be only two instructions that enforce "capabilities" : GET and PUT. They, and only they, clear the pipeline and ensure serialisation, trigger a trap/fault if the address falls in a forbidden range.

  The SR space can grow while keeping the very same management opcodes. You don't need to change the decoder if you add features, it's all in the SR circuits.
  

  KISS, guys.
  

• Choosing boolean instructions

  Yann Guidon / YGDES • 12/17/2020 at 02:56 • 0 comments

  My choice follows the classic SIMD Intel instructions, when 2 bits are available in the opcode (such as the #YGREC8) :

  • AND
  • OR
  • XOR
  • ANDN

  The last one is combined with AND and OR to create a MUX2 function for example.

  When 3 bits are available, like the #YASEP, I add the remaining ROP2 functions:

  • NAND
  • NOR
  • ORN
  • XORN

  There are 16 combinations for 2-inputs gates, 8 of them are "degenerate" (output if 0 or 1, or A or B or /A or /B, or a swap of inputs for ANDN/ORN).

  With the full 8 functions, any significant boolean calculation becomes possible and efficient. This is particularly useful for "lateral computations" such as #ANGOLA - A New Game Of Life Algorithm or even some particular implementations of crypto algos, where the LUT sequential lookups are replaced by parallel boolean computations.
  

• NAND or NOR ? A taxonomy of topologies

  Yann Guidon / YGDES • 12/16/2020 at 21:47 • 10 comments

  When you start to design a computer, you usually start with rule 1. Use binary, 2s complement numbers (unless you're @SHAOS or @alice crush) but it's only the beginning. You have to choose a technology, which is a complex entangled web of compromises and constraints.

  • cost
  • speed
  • size
  • space
  • availability
  • power consumption
  • interfacing with other stuff
  • what's new/fun/enticing/trending

  Of course,

  • if you use vacuum tubes, integrated circuits or FPGA, the rest is mostly moot due to their inherent properties.
  • I also assume you're not going anywhere near #Diode Resistor Logic either, though you might find inspiration here.
  • Relays have a great range of "topological expressiveness" that are worth a whole article.

  In fact, from here on, I guess you'll use discrete (MOS)FET or BJTs and things get downhill from there.

  Many Hackaday projects, and in particular the #Hackaday TTLers, love to explore and play with various ways to interconnect discrete transistors. It's just a notch below the thrill of designing an integrated circuit but way above that in the BMOW wow-factor. You can touch it, probe it, fix and patch it, show it off and impress...
  

  Creating a logic gate is an art in itself (ask Harvey about it), which draws from both boolean arithmetic and small-signal analog design, and we can dig in the literature, in the past or in the present, to find inspiration. Where each "logic family" differs is what they can express and how they perform each function. The range of possible functions is a sort of expressiveness, and this also deeply influences your higher-level design, as well as design methodology.

  This page is important because it gives you a taste of how miserable you will feel, once you get a few working gates. For example, if too few inputs are possible, the final circuit will be slower because of logic fan-in restrictions: for logic reduction, a 2-tree uses more stages than a 3-tree, and a 4-tree is faster, but might each gate might be slower, so you must find a balance somewhere. One typical example is how you design a XOR gate: it might cripple your critical datapath and speed if your logic family is too limited.

  The basic gates provide NOR and/or NAND, which I call "first order gates" because there is one level of inversion. Along with the MUX2, these are the "most basic gates" from which you can build all other circuits, but MUX2 is cheating because it contains both inversions, OR and AND. Building a computer with them is possible, but still a challenge ! You have to turn everything into a sequence of NOR or NANDs. This is why "expressiveness" is so important for architects and circuit designers : some families offer a wider range of gates that make life easier, critical datapaths shorter and circuits simpler.

  Another choice or constraint is your ability or willingness to use complementary transistors. If all you have, or can get, is a single type, then you are more limited in the possible topologies and you are forced to perform more boolean trickery with the few possible gates. OTOH if you can source both P and N types, you can exploit both NOR and NAND, or combine them in creative ways that could reduce both complexity and power.
  

  But mostly you end up with NANDs and/or NORs... you have to choose carefully !
  

  • Chances are you'll want to try your hand with a proven and reputed family : TTL, the one and true Transistor-to-Transistor Logic. One transistor per input and one for the output sounds reasonable and the basic gate is the NAND, such as the 74x00.
    You notice the weird transistor, which briefly existed in discrete form half a century ago. You can substitute a pair of classical transistors (tripoles) for each of them, which is mostly irrelevant in a digital design (unless your parts are really badly binned)
    You can't go wrong with such a classic but soon you'll be trying to get more performance with Baker clamps or speedup capacitors. Oh and you can't find discrete transistors with multiple emitters. In the end, the...

  Read more »

View all 53 project logs