Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RISC-V Assembler: Arithmetic

projectf.io

Post reply on HN
Print view View original

41–48 of 48 posts

Re: RISC-V Assembler: Arithmetic

#41

Post by _a_a_a_ »

inkyoto wrote: post #39
_a_a_a_ wrote: post #29

Earlier quoted context omitted.

Good post! ok, for rd = rs1 addu8 rs2 use rd = rs1 +u8 rs2 etc. The + stands out, more clearly indicating addition. (to me anyway) As for commutativity of +, it's not necessarily true. It depends entirely on what underlying operation + denotes. It's perfectly reasonable to use it for string concatenation, and that clearly isn't commutative. But if it's not in the case of an ISA, that's fine, just have the assembler r…

> rd = rs1 +u8 rs2 AMD 29k (its descendants are still alive) has two further ADD operations: – ADDU – IF unsigned overflow THEN trap (out of range), and – ADDCS – IF signed overflow THEN trap (out of range). The ADD instruction family in the HP PA-RISC 2.0 is, of course, one of the best ones out there: ADD,cmplt,carry,cond r1,r2,t Purpose: To do 64-bit integer addition and conditionally nullify the following instruct…

I appreciate the detail you've given and you clearly know your stuff, but I think your looking at it too deeply, at least compared to me. Basically, use a familiar notation where a familiar notation would be appropriate. Your complex ad example is a good case where it probably isn't.

> What about adding two decimals?

  rx = ry +bcd rz
I'm really thinking of simple, simple changes. As you point out some situations aren't appropriate for it, in other cases maybe it is. Or maybe I'm just plain wrong and it never is appropriate. But it's just a suggestion and worth considering, no?

Re: RISC-V Assembler: Arithmetic

#42

Post by throwaway71271 »

stockhorn wrote: post #5
throwaway71271 wrote: post #4

I love RISC-V assembler. I did a bit of x86 as stuff 20 years ago but hated it, now I wanted to teach my daughter some c and assembler and was thinking between arm and riscv, but riscv is just a joy to teach (I made a riscv assembler boardgame to help with the task https://punkx.org/overflow/ ) Recently I was rewatching Hackers(1995) and I also got excited about the same quote: > “RISC architecture is going to change…

Wow... Crazy this boardgame of yours. I'll definitly take a deeper look at this :). Thanks

thanks!

Re: RISC-V Assembler: Arithmetic

#43

Post by prabhu-yu »

lifthrasiir wrote: post #33
_a_a_a_ wrote: post #29

Earlier quoted context omitted.

Good post! ok, for rd = rs1 addu8 rs2 use rd = rs1 +u8 rs2 etc. The + stands out, more clearly indicating addition. (to me anyway) As for commutativity of +, it's not necessarily true. It depends entirely on what underlying operation + denotes. It's perfectly reasonable to use it for string concatenation, and that clearly isn't commutative. But if it's not in the case of an ISA, that's fine, just have the assembler r…

Obviously that doesn't generalize for opcodes with 0, 1, 3 or more input operands. As a concrete example, consider a fused multiply-add operation: `rd = fma rs1, rs2, rs3` is consistent, but how would you convert it to an infix notation?

pre-fix is the finest notation for many reasons. So, Intel syntax makes more sense than ATT syntax.

Even C functions are pre-fix. [function_name arg1, arg2 ...] If schools were teaching pre-fix, we would be in better position to appreciate Intel syntax.

Higher maths uses pre-fix, for example: y=f(x) unfortenately, above line is not pure prefix... = y f(x) would be pure pre-fix.

Re: RISC-V Assembler: Arithmetic

#44

Post by _a_a_a_ »

prabhu-yu wrote: post #43
lifthrasiir wrote: post #33

Earlier quoted context omitted.

Obviously that doesn't generalize for opcodes with 0, 1, 3 or more input operands. As a concrete example, consider a fused multiply-add operation: `rd = fma rs1, rs2, rs3` is consistent, but how would you convert it to an infix notation?

pre-fix is the finest notation for many reasons. So, Intel syntax makes more sense than ATT syntax. Even C functions are pre-fix. [function_name arg1, arg2 ...] If schools were teaching pre-fix, we would be in better position to appreciate Intel syntax. Higher maths uses pre-fix, for example: y=f(x) unfortenately, above line is not pure prefix... = y f(x) would be pure pre-fix.

  x++
is a postfix kind-of function

  a ? b : c
is ternary infix

Edit: arguably

  /* comment! */
is a function that takes an unquoted string. It's a no-op function so the compiler removes it at compile time (giggle)

Re: RISC-V Assembler: Arithmetic

#45

Post by IshKebab »

camel-cdr wrote: post #14
epcoa wrote: post #11

Earlier quoted context omitted.

> there's no official grammar Most architectures have something. Sparc had one (I still have the manual), PPC, 68k. I would even say x86 does as well but you can’t force its adoption, what AT&T and GNU wants to do on their own can’t be prevented. AT&T I suppose had the goal of making it all consistent, but I’m not sure if that was an improvement. Though I know of its vocal defendants. RISC-V might be the exception mo…

There is an assembly manual: https://github.com/riscv-non-isa/riscv-asm-manual/blob/maste...

That's not a specification for the grammar at all. It's just a guide for how to use RISC-V assembly. Not what we're talking about.

Re: RISC-V Assembler: Arithmetic

#46

Post by andromeduck »

IshKebab wrote: post #8

> ProTip: Hexadecimal literals are prefixed with 0x. I love the idea that someone could get to this page and not already know that! Also this nicely highlights my pet peeve with assembly: add rd, rs1, rs2 # rd = rs1 + rs2 It's very difficult to remember which parameter is the destination etc. IMO it would be much nicer if assembly had just a little more syntax for that sort of thing. E.g. rd = add rs1, rs2 t0 = li 5…

I've been pushing to open source a VLIW assembler/codec generator with some syntax like this but alas may not stay long enough to see it through.

Re: RISC-V Assembler: Arithmetic

#47

Post by inkyoto »

_a_a_a_ wrote: post #41
inkyoto wrote: post #39

Earlier quoted context omitted.

> rd = rs1 +u8 rs2 AMD 29k (its descendants are still alive) has two further ADD operations: – ADDU – IF unsigned overflow THEN trap (out of range), and – ADDCS – IF signed overflow THEN trap (out of range). The ADD instruction family in the HP PA-RISC 2.0 is, of course, one of the best ones out there: ADD,cmplt,carry,cond r1,r2,t Purpose: To do 64-bit integer addition and conditionally nullify the following instruct…

I appreciate the detail you've given and you clearly know your stuff, but I think your looking at it too deeply, at least compared to me. Basically, use a familiar notation where a familiar notation would be appropriate. Your complex ad example is a good case where it probably isn't. > What about adding two decimals? rx = ry +bcd rz I'm really thinking of simple, simple changes. As you point out some situations aren'…

> […] where a familiar notation would be appropriate.

And this is the problem I have been trying to point out. «+» comes from math, and – in the world of math – there are no bytes, no half-words, no overflows, no carry overs, no branches and no traps, and the imaginary «register» size is infinite – an addition always succeeds however large is the number. There are no decimals, no floating point numbers, either – in math, there is no distinction. There is just a lone exception being the handling of the explicit infinity values (-∞ and +∞). «Add and branch» or «add and trap» simply do not exist in math – math is abstract, and computing is concrete.

That is not the case in computing. The semantics of «add» varies across different CPU architectures, as the assembly language exposes the internal machinery and the internal state of a given CPU which may or may not be appropriate for another CPU. For example, RISC-V does not support the integer overflow flag, and most other CPU's do. Assembly is a 1:1 representation of the binary code for a given CPU, and that is where it stops.

In fact, I do find the charm in your proposal being along the lines of «r3 = r1 +.u8 r2», «r3 = r1 +.c r2 or branch label1», «r3 = r1 +.c r2 or trap overflow» etc. It will not be assembly though, more of a meta-assembly, which is fine. The real trouble is that the grammar will be able to handle just one ISA and might quickly become complex and unwieldy if ported to another ISA that has a rich set of addition operations that do not fit in the narrow constraints of such a design.

Re: RISC-V Assembler: Arithmetic

#48

Post by _a_a_a_ »

inkyoto wrote: post #47
_a_a_a_ wrote: post #41

Earlier quoted context omitted.

I appreciate the detail you've given and you clearly know your stuff, but I think your looking at it too deeply, at least compared to me. Basically, use a familiar notation where a familiar notation would be appropriate. Your complex ad example is a good case where it probably isn't. > What about adding two decimals? rx = ry +bcd rz I'm really thinking of simple, simple changes. As you point out some situations aren'…

> […] where a familiar notation would be appropriate . And this is the problem I have been trying to point out. «+» comes from math, and – in the world of math – there are no bytes, no half-words, no overflows, no carry overs, no branches and no traps, and the imaginary «register» size is infinite – an addition always succeeds however large is the number. There are no decimals, no floating point numbers, either – in…

I'm glad you like the possibility of using the addition symbol or some variation on it. The idea that it would be ISA independent never crossed my mind, and perhaps just as well because as you pointed out, it would bomb. For that (ie. portability), use an HLL.

I fully understand your criticism, entirely correct, that machine arithmetic does not behave like mathematical arithmetic. I diverged from you where you say that '+' is mathematical therefore has a predetermined meaning. It has a conventional mathematical interpretation, often related to number addition, but it is a convention only and can be bent as far as you like provided you're clear about it (and a bit of common sense too; defining '+' as a square root operation would be pretty bloody stupid). No symbol in mathematics has any intrinsic meaning, including '+'.

Thanks for interesting discussion!

Post reply on HN