3 ms·

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

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 reject it.

lifthrasiir 3y ago
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?
- _a_a_a_ 3y ago
  rd = rs1 * rs2 + rs3 It's no different from parsing if/then/else. Provided one assignment maps to one opcode, it's unambiguous.
- prabhu-yu 3y ago
  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.
  - _a_a_a_ 3y ago
    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)
inkyoto 3y ago
> 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 instruction. General register r1 and general register r2 are added. If no trap occurs, the result is placed in general register 1. The variable «carry_borrows» in the operation section captures the 4-bit carries resulting from the add operation. The completer, «complt», specifies whether the carry/ borrow bits in the PSW (the processor status word) are updated and whether a trap is taken on signed overflow. The completer, «carry», specifies whether the addition is done with carry in. So, under a certain set of conditions, a PA-RISC «add» operation, other than yielding an add product, can: – Can result in a trap on a signed overflow. – Can nullify the following instruction. An instruction mnemonic would like this: ADD,DC,TSV,C,<=,N r1, r2 – «add where r1 is less than or equal to negative of r2, and trap if specified conditions (DC,TSV) were met and nullify the following instruction» HP PA-RISC 2.0 also has an «add and branch» instruction, naturally, embellished with branch conditions, «cond»: ADDB,cond,n r1, r2, target If «n» flag is set, the «add and branch» will also nullify the following instruction, e.g. ADDB,*<=,N r1, r1, label_1 There are also an «add immediate left» instruction (a left shift and add a constant) and «halfword parallel add» (adds multiple halfwords in parallel with optional saturation). How does one encode all of that with a «+» operator? What about adding two decimals? The decimals are not used in modern CPU architectures, but they used to be a commonplace and were encoded by completely separate instructions. The bottom line is: the assembly language is a slightly more human friendly (e.g. «add r1, r2, r3») interface into the bit code (e.g. a fictional opcode of «0xf500010203» for «add r1, r2, r3») and, consequently, into the internal CPU machinery and its state, and is not a high programming language nor a testamenet to the laws of mathematics.
- _a_a_a_ 3y ago
  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?

lifthrasiir 3y ago

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?

_a_a_a_ 3y ago
rd = rs1 * rs2 + rs3 It's no different from parsing if/then/else. Provided one assignment maps to one opcode, it's unambiguous.
prabhu-yu 3y ago
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.
- _a_a_a_ 3y ago
  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)

inkyoto 3y ago

> 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 instruction. General register r1 and general register r2 are added. If no trap occurs, the result is placed in general register 1. The variable «carry_borrows» in the operation section captures the 4-bit carries resulting from the add operation. The completer, «complt», specifies whether the carry/ borrow bits in the PSW (the processor status word) are updated and whether a trap is taken on signed overflow. The completer, «carry», specifies whether the addition is done with carry in. So, under a certain set of conditions, a PA-RISC «add» operation, other than yielding an add product, can: – Can result in a trap on a signed overflow. – Can nullify the following instruction. An instruction mnemonic would like this: ADD,DC,TSV,C,<=,N r1, r2 – «add where r1 is less than or equal to negative of r2, and trap if specified conditions (DC,TSV) were met and nullify the following instruction» HP PA-RISC 2.0 also has an «add and branch» instruction, naturally, embellished with branch conditions, «cond»: ADDB,cond,n r1, r2, target If «n» flag is set, the «add and branch» will also nullify the following instruction, e.g. ADDB,*<=,N r1, r1, label_1 There are also an «add immediate left» instruction (a left shift and add a constant) and «halfword parallel add» (adds multiple halfwords in parallel with optional saturation). How does one encode all of that with a «+» operator? What about adding two decimals? The decimals are not used in modern CPU architectures, but they used to be a commonplace and were encoded by completely separate instructions. The bottom line is: the assembly language is a slightly more human friendly (e.g. «add r1, r2, r3») interface into the bit code (e.g. a fictional opcode of «0xf500010203» for «add r1, r2, r3») and, consequently, into the internal CPU machinery and its state, and is not a high programming language nor a testamenet to the laws of mathematics.

_a_a_a_ 3y ago
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?