News for hackers. Stuff that matters.
Re:Show HN: Z80 Compiler Visualization by vardump on Saturday April 29, 2017 @03:47PM (#14228347)
Code generation is probably missing somewhat trivial optimizations. Here's one example:

  int func(int x) {
      return x * 1;
  }
...still produces unnecessary stack manipulation:

   0000 C1            [10]   56 	pop	bc
   0001 E1            [10]   57 	pop	hl
   0002 E5            [11]   58 	push	hl
   0003 C5            [11]   59 	push	bc
   0004 C9            [10]   60 	ret
Plain "ret" would have been enough.
Re:Show HN: Z80 Compiler Visualization by Lerc on Saturday April 29, 2017 @05:45PM (#14228950)
Depends on how it expects the parameter and the result.

If the parameter is the second item down on the stack and the compiler wants the result in hl with the stack unchanged.

    pop bc
    pop hl
    push hl
    push bc
isn't redundant stack manipulation. it's moving stack values to bc and hl while keeping the stack unchanged.

Of course at another level a compiler should be able to inline x=>x*1 but that depends on the build architecture. If it's a linkable function then the contents may be opaque to the code that calls it.

Re:Show HN: Z80 Compiler Visualization by vardump on Saturday April 29, 2017 @06:26PM (#14229114)
Ok, seems like you're right.

In SDCC function params are always passed on stack, but return value in HL. So pop hl/push hl moves function parameter to return value register HL. (pop/push bc is of course just used to get past return address value in stack.)

Seems odd compiler doesn't pass parameters in registers in a relatively register rich z80 arch.

Re:Show HN: Z80 Compiler Visualization by Questron on Sunday April 30, 2017 @07:34AM (#14231071)
There's also something else: Try shifting unsigned char x to right. >> 1 through 3 produce correct results, 4 changes the shift to some optimization too early, and the >> 5 the correctly optimized version. It's definitely not a very good compiler.