Qnice – An Elegant 16 Bit Processor

http://qnice.sourceforge.net/

by doener • 6 years ago

81 50 6 years ago

qnice.sourceforge.net

Ah neat!

Very recently I picked up an FPGA dev board and started playing with implementing my first toy soft-CPU. For fun, and definitely not for profit, I decided to design my own ISA for it.

I decided to see if I could make a RISC-y MISC (minimal instruction set computer) design. From what I could see a lot of MISC-based computers had quite complex instructions.

While my resulting ISA is likely quite crap, being my very first ISA ever, it's been quite a fun exercise so far. I programmed quite a lot of asm back in the days, but thinking about which instructions are needed and why was something else.

colatkinson• 6 years ago

I've always wanted to do exactly what you just described! Can you recommend any resources to get started with FPGA design for a software dev?

magicalhippo6• 6 years ago

I've so far been quite happy with the iCE40UP5k[1] based dev kit I got, though there are a lot of options out there[2].

The iCE40 FPGAs are a bit whimpy compared to Altera and Xilinx offerings from what I understand, but I really liked the idea of an open-source toolchain[3][4] being available.

To get a taste without committing cash you could just use a simulator[5], which I imagine you'd be using a fair bit anyway as it allows you easier access to the internal state.

As to actually programming, I've found the following resources useful. I started with Verilog mainly because code-gen tools like nMigen[6] generate Verilog, but for writing by hand it seems VHDL is preferred.

Anyway, links, first off some exercises to get going[7]. Introduction to Verilog[8], also has a nice general overview of HDL. Details of how non-blocking vs blocking statements in Verilog works[9], quite specific but was very informative for me.

There's also quite a lot of activity over at Reddit[10], and good experiences over at the EEVBlog forums[11].

As I said I just got started so no expert yet :)

[1] https://www.digikey.com/product-detail/en/lattice-semiconduc...

[2] https://joelw.id.au/FPGA/CheapFPGADevelopmentBoards

[3] https://symbiflow.github.io/

[4] https://github.com/cliffordwolf/icestorm

[5] http://iverilog.icarus.com/

[6] https://nmigen.org

[7] https://www.fpga4fun.com/

[8] https://www.chipverify.com/verilog/verilog-tutorial

[9] http://sunburst-design.com/papers/CummingsSNUG2002Boston_NBA...

[10] https://www.reddit.com/r/FPGA/

[11] https://www.eevblog.com/forum/fpga/

magicalhippo6• 6 years ago

Oh yeah also forgot to add that once you have some hardware you'll most likely want a cheap logic analyzer that supports sigrok[1] like this[2] one. Some LEDs and a breadboard etc is useful too.

[1] https://sigrok.org/

[2] https://www.aliexpress.com/item/32877931876.html (random seller link)

saagarjha• 6 years ago

Has anyone implemented this in hardware yet?

xellisx2• 6 years ago

http://qnice-fpga.com/

dimator• 6 years ago

that page has a WebRing at the bottom! what a blast from the past.

this is what sites used to do before aggregators and search engines dominated.

ngcc_hk• 6 years ago

Also got some spare fpga, any test required?

titzer2• 6 years ago

I really like conditional subroutine calls. I wish x86 had them. It makes it really easy to inline a fastpath of some safety check (e.g. nullcheck, bounds check, write barrier, etc), and have the slowpath be factored out to a common place. What PL implementations like the JVM, JavaScript engines, etc typically have to do without this is they insert a conditional branch to "deferred code" which is at the end of the function (statically predicted not-taken), but that deferred code can't be shared, because it needs to branch back to the mainline code. That costs code size. A conditional subroutine call is exactly the right mechanism to solve this!

aparashk• 6 years ago

Can’t agree more!

projektfu• 6 years ago

Curious why it leaves out PC-relative addressing. By 1990 it seems that was one of the obvious shortcomings of 8086.

Taniwha• 6 years ago

Very pdp11ish, even looks like it supports "mov -(pc), -(pc)"

(if you ignore the register windows and the lack of byte instructions - word addressing harks back to a previous age)

throwaway_pdp099• 6 years ago

Tangential question, something I've always wanted to ask. The ISA here is given by example, here's a couple

  MOVE src, dst:     dst := src 
  ADD src, dst:     dst := dst + src

I have always wondered why assembler is written the first way

  MOVE src, dst
  ADD src, dst

rather than the far more intuitive (and slightly more compact) second, something like

  dst := src 
  dst += src

This also completely eliminates questions about which direction data goes, is 'mov a,b' a:=b or b:=a for example.

I can't see any reason for not using the established C-type notation, so why is the original style always perpetuated?

I'm aware that C approximately maps onto the original PDP ISA and has been called a high-level assembler, true or not that's irrelevant, but why the higher-level syntax has never made its way to lower level ASM has baffled me.

gtirloni• 6 years ago

AT&T vs Intel syntax

Zardoz84• 6 years ago

It's Intel vs AT&T syntax :

    Intel: mov eax, 4
    AT&T : movl $4, %eax

One could interpret that doing ADD a, b, c would be "do a + b and put in c"

titzer2• 6 years ago

It's very useful to have the actual instruction mnemonics spelled out, instead of relying on an implicit (often overloaded) definition of "+". E.g. there might be a 8-bit, 16-bit, 32-bit integer add, a 32-bit, 64-bit floating point add, a 16x8 vector integer add, etc.

throwaway_pdp099• 6 years ago

Hm, good point. How about

  a +=L b

for a long type? Or have a non-annotated opcode for the native machine word size (just '+') and annotated for anything smaller (edit: anything other) - ('+B' for byte addition).

An alternative and perhaps much better higher-level solution is to have typed ASM. I believe there is work done in this area (quick search gets http://www.cs.cornell.edu/talc/), which would allow the type to be implicit but checkably safe but for the occasional explicitly needed coercions.

pjc502• 6 years ago

why the higher-level syntax has never made its way to lower level ASM has baffled me

Traditionally assembler was both for bootstrap processes and for the older heavily resource constrained systems, so there was a lot of emphasis on making it as simple to parse as possible; opcode first, then arguments, because the opcode is first in the byte stream of almost all variable-instruction length systems.

And of course no support for complex expressions, so no point in building a full mathematic expression parser.

Then there's the question of which add instruction you want. The vast proliferation of instructions in things like AVX gives you "VADDPS" and even "VFMSUBADD132PD", which expands to: https://www.felixcloutier.com/x86/vfmsubadd132pd:vfmsubadd21...

    IF (VEX.128) THEN
        DEST[63:0]←RoundFPControl_MXCSR(DEST[63:0]*SRC3[63:0] + SRC2[63:0])
        DEST[127:64]←RoundFPControl_MXCSR(DEST[127:64]*SRC3[127:64] - SRC2[127:64])
        DEST[MAXVL-1:128] ←0
    ELSEIF (VEX.256)
        DEST[63:0]←RoundFPControl_MXCSR(DEST[63:0]*SRC3[63:0] + SRC2[63:0])
        DEST[127:64]←RoundFPControl_MXCSR(DEST[127:64]*SRC3[127:64] - SRC2[127:64])
        DEST[191:128]←RoundFPControl_MXCSR(DEST[191:128]*SRC3[191:128] + SRC2[191:128])
        DEST[255:192]←RoundFPControl_MXCSR(DEST[255:192]*SRC3[255:192] - SRC2[255:192]
    FI
    VFMSUBADD213PD DEST, SRC2, SRC3
    IF (VEX.128) THEN
        DEST[63:0]←RoundFPControl_MXCSR(SRC2[63:0]*DEST[63:0] + SRC3[63:0])
        DEST[127:64]←RoundFPControl_MXCSR(SRC2[127:64]*DEST[127:64] - SRC3[127:64])
        DEST[MAXVL-1:128] ←0
    ELSEIF (VEX.256)
        DEST[63:0]←RoundFPControl_MXCSR(SRC2[63:0]*DEST[63:0] + SRC3[63:0])
        DEST[127:64]←RoundFPControl_MXCSR(SRC2[127:64]*DEST[127:64] - SRC3[127:64])
        DEST[191:128]←RoundFPControl_MXCSR(SRC2[191:128]*DEST[191:128] + SRC3[191:128])
        DEST[255:192]←RoundFPControl_MXCSR(SRC2[255:192]*DEST[255:192] - SRC3[255:192]
    FI

throwaway_pdp099• 6 years ago

We don't have resource constrained systems now. I doubt parsing asm ever took up much anyway.

I'm not suggesting we permit complex (ie. general opcode combination) expressions. I deliberately never suggested it.

As to straighforward FMAC-type instructions, that's even clearer in my notation: a += b * c

But As for the proliferation of those add types you linked to, OK, possibly valid, but how much of this are you going to be manually writing compared to the very mundane style non-simd non-packed instructions? My guess is very little as you have relatively few number of such instructions (although they're doing a great deal of work over streams of data, but that's not relevant).

pacman128• 6 years ago

Randall Hyde created a higher level assembler back in the 90's. It supported writing C like control statements, etc. It doesn't look like it has been updated to x86-64, still just 32-bit.

https://en.wikipedia.org/wiki/High_Level_Assembly

MaxBarraclough• 6 years ago

Your sense of which is intuitive, isn't universal. When we say Move this over there, it's left-to-right.

why the higher-level syntax has never made its way to lower level ASM has baffled me.

It has. In the AT&T x86 assembly syntax, MOV is left-to-right. (In the Intel syntax, though, it's right-to-left.)

https://en.wikipedia.org/w/index.php?title=X86_assembly_lang...

oso2k2• 6 years ago

I like to say that AT&T follows natural English flow and byte order of the finally assembled binary code. Intel followed the more mathematically oriented syntax. Might be a bit back duck syndrome since I learned math and Intel first, but Intel seemed more intuitive to me as well.

   AT&T
   ASM             | English          | Binary
   MOVE src, dst   | src -> dst       | 01 src dst
   ADD src, dst    | src + dst -> dst | 02 src dst
                     or
                     src + dst = dst

Compared to

   Intel
   ASM             | English          | Binary
   MOV dst, src    | dst <- src       | 01 dst src
   ADD dst, src    | dst <- dst + src | 02 dst src
                     or
                     dst = dst + src
                     dst += src

<- could be read as `loaded from`

-> could be read as `stored to`

Notice the RISC-y-ness of that.

However, ISAs developed later and are primarily MIPS-like follow Intel convention and extend it because it aligns better with 3AC [0] SSA[1] based optimizations.

[0] https://en.wikipedia.org/wiki/Three-address_code

[1] https://en.wikipedia.org/wiki/Static_single_assignment_form

ape4• 6 years ago

Misspelling "architectur" on the 3rd line doesn't exactly inspire confidence.

arethuza• 6 years ago

Has there ever been any attempts to systematically generate processor instruction set designs, evaluate them against 'real' code and measure the results?

Edit: You'd need to generate compiler back ends for each design as well, which might be fun...

carapace2• 6 years ago

I don't have a link handy to give you but, yes, people have done things like that. Look into Prolog research on compiling.

chalst4• 6 years ago

16 registers divided into to areas: R0 to R7 are in fact a window to a register bank containing 256 times 8 registers while R8 to R15 are fixed. This architecture makes subroutine calls and saving registers very easy (just increment/decrement the register bank pointer which is part of the status register). All in all QNICE features 256 * 8 + 8 = 2056 registers.

This is indeed nice and the kind of thing whose availability can affect the design of low-level languages, e.g. non-ISO local variables in a Forth dialect.

Cf. http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Gfor...

zimpenfish• 6 years ago

Pretty neat but doesn't seem to be making it to the Real World(tm) despite several attempts.

https://en.wikipedia.org/wiki/Register_window

chalst4• 6 years ago

Decent link, thanks.

It doesn't surprise me that having more visible registers and doing a good job of register allocation in the compiler is a better strategy (i.e., both more efficient and more flexible), but doing so means you are not so close to the metal. From the point of view of an efficiency feature that doesn't ask for complexity in the compiler, I see some appeal to register windows.

throwaway_pdp099• 6 years ago

This sounds like Spark's register windows https://en.wikipedia.org/wiki/SPARC#Features

I got it from a very reliable source, someone who was involved in evolving that hardware, that this feature caused Sun "an awful lot of pain" (his words, best I can recall).

My understanding is that it greatly destroyed the ability to do out-of-order execution, which was on top of the original designer's failure to understand what the compiler could do with inlining that would largely negate the value of this. From what I've read over the years, the Sparc hardware guys didn't talk to the compiler guys - a trap the designers of the DEC Alpha very carefully did not fall into.

Since this is a teaching project, I'm sure that feature is fine, but just saying.

chalst4• 6 years ago

This is a very nice comment.

The Wikipedia article would benefit from a citeable source for the problems they had: is that something you could help find?

FeepingCreature• 6 years ago

ABRA because it jumps away?

Qnice – An Elegant 16 Bit Processor

Related Stories