Exhibit A is vaguely understandable if the code in &00001e2c is in a different .o file.

Exhibit B would be easier to understand if the original source is in place.

Exhibit C is inexcusable! (Original source might be good here to see why it decided to opt for that approach)

Exhibit D is taking bits 12 to 15 of R1, and using them as the pointer offset - for a few seconds, I couldn't think of a way of doing it which would be smaller, but then I thought of this:

AND R3, R1, #&F000
...
CMP R3, #&F000
...
STR R1, [R4, R3, LSR#10]

Unfortunately, there is the possibility that R3 is used after this fragment, but I'm guessing you've not been too clip happy

As many flaws as GCC seems to have with its optimiser, the compiler I'm currently using at work (which I probably can't name for legal reasons ) seems to be about 10 million times worse.

Never even heard of it. Should I be glad?

People who in my experience have produced dreadful compilers include: GNU, Greenhills, Borland, IAR, and loads others.

I thought it'd be a good idea for me to get to grips with something like that before venturing into GCC and the Acorn/Castle/ROOL tools under RISC OS (and also disregarding the small matter of not being a programmer).

People who in my experience have produced dreadful compilers include: GNU, Greenhills, Borland, IAR, and loads others.

What's up with Borland? I thought it'd be a good idea for me to get to grips with something like that before venturing into GCC and the Acorn/Castle/ROOL tools under RISC OS (and also disregarding the small matter of not being a programmer).

I think rjek means the machine code output from the compiler.

TBH you can't expect a compiler to weave any decent code anyway it's just impossible

But from personal experience a human will always produce faster, more optimal code than a compiler.

GCC on x86

I bet a compiler will produce better code than you for all of Cortex-M4, IA64, HPPA, POWER, Alpha, SPARC, ARC, and MIPS

The quality of the instructions fed to the CPU is not the only performance issue. I've seen delightfully over-optimised assembler programs that have been slower than ones written in BBC Basic because the author spent more time tuning the code than thinking about using the right algorithm.

I bet a compiler will produce better code than you for all of Cortex-M4, IA64, HPPA, POWER, Alpha, SPARC, ARC, and MIPS

The quality of the instructions fed to the CPU is not the only performance issue. I've seen delightfully over-optimised assembler programs that have been slower than ones written in BBC Basic because the author spent more time tuning the code than thinking about using the right algorithm.

I was implying the coder actually knew what they were doing, not just anyone. I'm suprised anything ran slower than BBC BASIC, that is a feat.

I've seen delightfully over-optimised assembler programs that have been slower than ones written in BBC Basic because the author spent more time tuning the code than thinking about using the right algorithm.

        SUBS    R2,R0,#&1C
        BPL     |L00000420|
        SUBS    R2,R0,#8
        BMI     |L0000048C|
        SUBS    R2,R2,#4
        MOVMI   R1,#1
        BMI     |L00000464|
        SUBS    R2,R2,#4
        MOVMI   R1,#2
        BMI     |L00000464|
        SUBS    R2,R2,#4
        MOVMI   R1,#3
        BMI     |L00000464|
        SUBS    R2,R2,#4
        MOVMI   R1,#4
        BMI     |L00000464|
        SUBS    R2,R2,#4
        MOVMI   R1,#5
        BMI     |L00000464|
|L00000420|
        SUBS    R2,R2,#4
        MOVMI   R1,#6
        BMI     |L00000464|
        SUBS    R2,R2,#4
        MOVMI   R1,#7
        BMI     |L00000464|
        SUBS    R2,R2,#4
        MOVMI   R1,#8
        BMI     |L00000464|
        SUBS    R2,R2,#4
        MOVMI   R1,#9
        BMI     |L00000464|
        SUBS    R2,R2,#4
        MOVMI   R1,#&0A
        BMI     |L00000464|
        SUB     R2,R2,#4
        MOV     R1,#&0B
|L00000464|

GCC for ARM has been getting progressively more awful over the past 5 years or so. Roll on LLVM and Clang.

#define LHS ((LHSReg == 15) ? R15PC : (state->Reg[LHSReg]))
#define R15PC (state->Reg[15] & R15PCBITS)
#define R15PCBITS (0x03fffffcL)

typedef struct {
  int Reg[16];
} state_t;

int func(state_t *state, int LHSReg) {
  return LHS;
}

clang -O3 -marm -S test.c --target=arm-linux-gnueabi -mcpu=cortex-a8

 cmp   r1, #15
 ldrne r0, [r0, r1, lsl #2]
 ldreq r0, [r0, #60]
 biceq r0, r0, #-67108861
 bx    lr

I should probably check Norcroft when I get home, hopefully that can restore my faith in humanity.

 CMP   a2,#&f
 LDRNE a1,[a1,a2,LSL #2]
 LDREQ a2,[a1,#&3c]!
 BICEQ a1,a2,#&fc000003
 MOV   pc,lr

#define THING (fudge*fudge)
#define R15PCBITS (0x03fffffcL)

int func(int LHSReg, int fudge) {
  if (LHSReg == 15) {
    return THING & R15PCBITS;
  } else {
    return THING;
  }
}

func(int, int):
        cmp     r0, #15
        muleq   r1, r1, r1
        biceq   r0, r1, #-67108861
        mulne   r0, r1, r1
        bx      lr

func(int, int):
        cmp     r0, #15
        lsl     r0, r1, #1
        biceq   r0, r0, #-67108861
        bx      lr

Any sane person would calculate THING once and use the result in both halves of the if. But that appears to be beyond the capabilities of GCC.

func(int, int):
        cmp     r0, #15
        muleq   r1, r1, r1
        biceq   r0, r1, #-67108861
        mulne   r0, r1, r1
        bx      lr

To be fair, this code does only calculate it once Still, there's a cycle that could be saved.

  asm volatile (
    "\n0:"
    "\n\tldxr %[result], [%[first]]"
    "\n\tadd %[tmp], %[result], %[size]"
    "\n\tstxr %w[flag], %[tmp], [%[first]]"
    "\n\tcbnz %w[flag], 0b"
  : [flag] "=r" (flag), [tmp] "=r" (tmp), [result] "=r" (result)
  : [size] "r" (count * 4096), [first] "r" (&core_0_storage->next_free_page)
  );

    301c:       f9448001        ldr     x1, [x0, #2304]
    3020:       91004021        add     x1, x1, #0x10
    3024:       c85f7c20        ldxr    x0, [x1]
    3028:       52820002        mov     w2, #0x1000                     // #4096
    302c:       f9000420        str     x0, [x1, #8]
    3030:       8b020001        add     x1, x0, x2
    3034:       c8027c21        stxr    w2, x1, [x1]
    3038:       35ffff62        cbnz    w2, 3024 <allocate_pages.constprop.0+0xc>

  register u64 tmp, blocked;
  register void *result;

  do {
    asm volatile (
      "\n\tldxr %[result], [%[first]]"
      "\n\tadd %[tmp], %[result], %[size]"
      "\n\tstxr %w[flag], %[tmp], [%[first]]"
    : [flag] "=r" (blocked), [tmp] "=r" (tmp), [result] "=r" (result)
    : [size] "r" (count * 4096), [first] "r" (&core_0_storage->next_free_page)
  );
  } while (blocked);

  return result;

GCC: I'll just use the same register for tmp and first, what could possibly go wrong?

This happens because your asm constraints are wrong (and are still wrong in your second version)

If your inline asm performs register writes before register reads, then those outputs must be declared as early clobber, ie "=&r" (var)

  asm volatile (
    "\n0:"
    "\n\tldxr %[result], [%[first]]"
    "\n\tadd %[tmp], %[result], %[size]"
    "\n\tstxr %w[flag], %[tmp], [%[first]]"
    "\n\tcbnz %w[flag], 0b"
  : [flag] "=r" (flag), [tmp] "=&r" (tmp), [result] "=&r" (result)
  : [size] "r" (count * 4096), [first] "r" (&core_0_storage->next_free_page) );

    305c:       f9409801        ldr     x1, [x0, #304]
    3060:       91004021        add     x1, x1, #0x10
    3064:       c85f7c20        ldxr    x0, [x1]
    3068:       8b020003        add     x3, x0, x2
    306c:       c8017c23        stxr    w1, x3, [x1]   <<< Here; I still want to use x1 (first)
    3070:       35ffffa1        cbnz    w1, 3064 <allocate_pages.constprop.0+0x10>

(i.e. without the =&r for flag) it uses (part of) the same register for flag as for the [first], which is an input that I still want to use.

(i.e. without the =&r for flag) it uses (part of) the same register for flag as for the [first], which is an input that I still want to use.

Your code writes to flag, then, if you go round the loop, read first. This is the same write-before-read situation which necessitates the early clobber flag.

    asm volatile (
      "\n  ldxr %[result], [%[first]]"
      "\n  add %[tmp], %[result], %[size]"
      "\n  stxr %w[flag], %[tmp], [%[first]]"
    : [flag] "=r" (blocked), [tmp] "=r" (tmp), [result] "=r" (result)
    : [size] "r" (count * 4096), [first] "r" (&core_0_storage->next_free_page)
  );

Am I right in thinking that the compiler assumes that once its used an input, it can safely re-use that register for one of the outputs? That would mean that, in the above example, I was just lucky that it didn't use the register it chose for "first" for one of the output registers, which meant that the input value of "first" was still available for the third line.

Am I right in thinking that the compiler assumes that once its used an input, it can safely re-use that register for one of the outputs? That would mean that, in the above example, I was just lucky that it didn't use the register it chose for "first" for one of the output registers, which meant that the input value of "first" was still available for the third line.

The compiler does not analyse the text in the asm block at all. The compiler models the inline asm as a sequence of

1. read all inputs
2. do something
3. write all outputs

So the writes of the output registers overwrite ("clobber") the previous content of the registers late in the process. Where there is a write before a read, it overwrites the previous value "early" in the process, hence "early clobber".

You're right that the non-loopy version was just lucky.

Looking at the constraints you're using again, the use of "first" is also wrong. You need to tell the compiler that you are accessing memory, or it could move a store to that address below the asm. So your constraint should be:

[first] "m" (core_0_storage->next_free_page)

and you should refer to it as
%[first] (ie without the [] around it)

You should also get better code as the compiler won't have to generate an ADD instruction to implement &core_0_storage->next_free_page.

/tmp/ccPRcVRj.s: Assembler messages:
/tmp/ccPRcVRj.s:1348: Error: the optional immediate offset can only be 0 at operand 2 -- `ldxr x0,[x2,16]'
/tmp/ccPRcVRj.s:1350: Error: the optional immediate offset can only be 0 at operand 3 -- `stxr w3,x4,[x2,16]'

  VirtualMemoryBlock *vma = allocate_contiguous_memory( &all_memory, allocate, 12 * sizeof( VirtualMemoryBlock ) );

  vma[0].start_page = 0;
 284:   d2800001        mov     x1, #0x0                        // #0
 288:   f9400020        ldr     x0, [x1]
 28c:   92689c00        and     x0, x0, #0xffffffffff000000
 290:   f9000020        str     x0, [x1]
 294:   d4207d00        brk     #0x3e8

  static inline int return0(void) { return 0; }
  int provoke_div0_warning(void) { return 1 / return0(); }

which gets turned into a single trapping instruction

(aarch64)
0000000000000018 <provoke_div0_warning>:
  18:	d4207d00 	brk	#0x3e8