It's perfectly reasonable to advise why assembly language isn't the best thing to gravitate toward; indeed, the OP himself concluded that RISC-V assembler syntax was too much for him.
Quite ridiculously, as RV32I is significantly simpler to describe and learn than something like 6502 or Z80, let alone the PIC clone Ubicom SX-28 he says he used before. And then a good order of magnitude easier to actually get things done in. I say this as someone who to this day still writes 6502 and Z80 assembly language code (and have since 1980 or so).
I have no idea about the RISC-V assembly, as I have not looked at it yet. Having used 6502, Z80 and 8051 assembly quite a lot back in the day, and you saying it is easier to learn it than those, I should not have any trouble with it then. 
Looking specifically at RV32I there are only 37 instructions, documented together in a single chapter, you can tell compilers to use it with
-march=rv32i.
This is 37 actual instructions to learn, not like 6502's 56 mnemonics, each of which can have up to eight different addressing modes, for 151 total instructions.
There are 32 registers x0-x31 plus PC. All registers are identical and interchangeable except x0 is always equal to 0 (discards attempts to write to it). There is nothing else. In particular, no condition codes or status register.
At the assembly language level there are only four kinds of instructions:
- three registers rd, rs1, rs2:
- rd = rs1 op rs2 where op is add, sub, and, or, xor, sll, srl, sra, slt, sltu That's 3 shifts, and 2 instructions that compare rs1, rs2 and set rd to 0 or 1
- two registers rd, rs1 plus a sign extended 12 bit constant:
- rd = rs1 op const where op is the above except sub (add the -ve instead)
- rd = mem[rs1 + const] with size b, h, w plus unsigned option for b, w (LW, LBU etc)
- rd = pc + 4; pc = rs1 + const (JALR)
- two registers rs1, rs2, plus a 12 bit sign extended constant
- mem[rs1 + const] = rs2 with size b, h, w (SW etc)
- pc = pc + const if rs1 op rs2 where op is eq, ne, lt, ltu, ge, geu (BNE, BLT etc)
- one register, rd, plus a sign-extended 20 bit constant
- rd = pc + 4; pc = pc + const (JAL)
- rd = const << 12 (LUI)
- rd = pc + (const << 12) (AUIPC)
That is IT. There is nothing more. With this you can efficiently compile all of C/C++ or any other language (using softfp if floating point is needed).
Couple of minor wrinkles:
- conditional branches and JAL support double the range (±4K, ±1M) by representing only even numbers. The binary encoding is a little more complicated than you might expect, but this affects only people writing assemblers or disassemblers or coding in binary/hex by hand.
- link register and stack pointer do not exist in the ISA, any register(s) except x0 can be used for these functions. Standard tools and libraries use x1 for RA (LR) and x2 for SP. Some low level runtime library code uses x5 as a LR to avoid disturbing x1.
- by convention certain registers use the mnemonic aliases a0-a7 (function argument / return / temps), t0-t6 (temps), and s0-s11 (locals preserved over function calls). There is also gp (globals pointer) and tp (thread-local globals pointer).
Congratulation! You now know everything about RV32I.
The last assembly I looked at was ARM (armv5tej) when I reverse engineered the FNIRSI 1013D. Did not find it to difficult, but writing a full application in it would be cumbersome.
Not a bad ISA, but definitely more complex.
In a way it is admirable that someone has been writing assembly even on x86 under Windows OS, but also kind a stupid with the availability of higher level languages that perform just as well and allow you to get a large program up and running way quicker, no matter how experienced one is in assembly. Also when it has to be maintained for a longer period of time, by different people, assembly language is not the best choice.
SOMEONE has to know how to write asm, even if only people writing compilers. And emulators. And designing ISAs. And building hardware.
It's not normally an efficient idea to write an entire application in asm in practise. It's too brittle to spec changes. It's unmanageable unless you follow a lot of conventions and boilerplate things in a way that makes code less efficient than a good modern compiler will. And it's non-portable to other ISAs. And will by definition only be optimised for a single µarch of even the same ISA.
But knowing HOW is very useful, as is actually doing it for the odd critical function, especially if your CPU has instructions that don't map easily into C.
Home
Help
Search
Login
Register
