5 ms·

The PDP-11 that C originally targeted had address modes to support the stack. Pre-increment and post-decrement therefore did not require a separate instruction

The PDP-11 that C originally targeted had address modes to support the stack. Pre-increment and post-decrement therefore did not require a separate instruction; they were free. After the PDP-11 went the way of the dodo, both forms took a machine cycle so it (mostly) became a stylistic issue. (The two operators have different semantics, but the trend to avoid side-effects in expressions means that both are most often used in a single expression statement like "++x;" or "x++;", so it comes down to your preferred style.)

zabzonk 2y ago
Please explain what you mean by "a separate instruction".
- spc476 2y ago
  Some idiomatic C code to copy a string (I'm not saying this is good C code, but it's just an example): while(*d++ = *s++) ; On the Motorola 68000 (based somewhat on the PDP-11) the code would look like: loop: move.b (a0)+,d0 move.b d0,(a1)+ bne loop while on the x86 line, it would be: loop: mov al,[rsi] mov [rdi],al inc rsi ; extra instruction! inc rdi ; extra instruction! cmp al,0 jne loop Yes, there are better ways to write that code for both the 68K and x86, but I hope this gets the point across.
  - wang_li 2y ago
    > loop: move.b (a0)+,d0 move.b d0,(a1)+ ... > loop: mov al,[rsi] mov [rdi],al This hurts my brain. When we invent time machines I'm going to use it to go back and slap whoever at intel came up with that operand order.
    - spc476 2y ago
      It hurts less if you think of it like assignment: al = [rsi] [rdi] = al
    - int_19h 2y ago
      memcpy etc also take the destination as their first argument, and it mirrors the usual way we write assignments. Personally I always found Intel syntax to be more straightforward, but I think it's ultimately down to whatever one was exposed to first. I wonder sometimes why we keep insisting on the "OP ARG, ARG" format in general for assembly. Why not something like `MOV X -> Y` that would make it absolutely clear and unambiguous? For that matter, why not `COPY X -> Y`, since that's what it actually does?
- wpollock 2y ago
  A MOV and an INC, as opposed to just the MOV.

zabzonk 2y ago

Please explain what you mean by "a separate instruction".

spc476 2y ago
Some idiomatic C code to copy a string (I'm not saying this is good C code, but it's just an example): while(*d++ = *s++) ; On the Motorola 68000 (based somewhat on the PDP-11) the code would look like: loop: move.b (a0)+,d0 move.b d0,(a1)+ bne loop while on the x86 line, it would be: loop: mov al,[rsi] mov [rdi],al inc rsi ; extra instruction! inc rdi ; extra instruction! cmp al,0 jne loop Yes, there are better ways to write that code for both the 68K and x86, but I hope this gets the point across.
- wang_li 2y ago
  > loop: move.b (a0)+,d0 move.b d0,(a1)+ ... > loop: mov al,[rsi] mov [rdi],al This hurts my brain. When we invent time machines I'm going to use it to go back and slap whoever at intel came up with that operand order.
  - spc476 2y ago
    It hurts less if you think of it like assignment: al = [rsi] [rdi] = al
  - int_19h 2y ago
    memcpy etc also take the destination as their first argument, and it mirrors the usual way we write assignments. Personally I always found Intel syntax to be more straightforward, but I think it's ultimately down to whatever one was exposed to first. I wonder sometimes why we keep insisting on the "OP ARG, ARG" format in general for assembly. Why not something like `MOV X -> Y` that would make it absolutely clear and unambiguous? For that matter, why not `COPY X -> Y`, since that's what it actually does?
wpollock 2y ago
A MOV and an INC, as opposed to just the MOV.