Test your compilers!

[tufty]

Please show some proof of this, or I'll assume you're blowing smoke. A good proof would be a decent-sized piece of modern, portable, self-contained C or C++ code (preferably both), compiled to ELF format. Please feel free to max out the optimisation. I'll take the time to build the latest gcc and llvm suites and provide comparisons.

Ok what would you recomend? Something that is ANSI C complient (Remember that the last ANSI C to date is C 99, C11 is ISO only not ANSI), or uses the level of C++ suppoerted by Norcroft. This means also something that does not use any of the Propritary GCC extensions (copyed by many other compilers still not part of the base standard).

Try this for size : https://github.com/humppa/tiraes

Small enough for us to easily tear the results apart, complex enough to give the optimisers something to go on. Compile for 1176jzf-s (the Pi's processor) if you can, otherwise tell me what processor you want to go for.

And ok I will do it as an ELF. I do not understand the advantage if using C as there is nothing extra that AOF/AIF does not cover. If you would like I could also give a stab at a GCC Compile using GCC 4.1.2 on RISC OS.

ELF means that we have tools to play with the results. I don't have anything to play with AIF or AOF.

gcc 4.1 could be interesting, although it's waaaaaaay behind the cutting edge. I'm currently at 4.6.2, and even that's significantly out of date (gcc is currently at 4.8.2)

Though RISC OS used to be the ONLY OS for the ARM CPU

And CFront used to be the only C++ compiler. Times change.

Oh, and from the platform options help in gcc 4.6.2 :

Known ARM CPUs (for use with the -mcpu= and -mtune= options):
cortex-m0, cortex-m1, cortex-m3, cortex-m4, cortex-r4f, cortex-r4,
cortex-a15, cortex-a9, cortex-a8, cortex-a5, arm1156t2f-s, arm1156t2-s,
mpcore, mpcorenovfp, arm1176jzf-s, arm1176jz-s, arm1136jf-s, arm1136j-s,
arm1026ej-s, arm926ej-s, fa726te, fmp626, fa626te, fa606te, iwmmxt2, iwmmxt,
xscale, arm1022e, arm1020e, arm10e, arm968e-s, arm966e-s, arm946e-s, arm9e,
arm1020t, arm10tdmi, ep9312, arm940t, arm922t, arm920t, arm920, arm9tdmi,
arm9, arm740t, arm720t, arm710t, arm7tdmi-s, arm7tdmi, fa626, fa526,
strongarm1110, strongarm1100, strongarm110, strongarm, arm810, arm8,
arm7dmi, arm7dm, arm7m, arm7500fe, arm7500, arm7100, arm710c, arm720,
arm710, arm700i, arm700, arm70, arm7di, arm7d, arm7, arm620, arm610, arm600,
arm60, arm6, arm3, arm250, arm2

Known ARM architectures (for use with the -march= option):
iwmmxt2, iwmmxt, ep9312, armv7e-m, armv7-m, armv7-r, armv7-a, armv7,
armv6-m, armv6t2, armv6zk, armv6z, armv6k, armv6j, armv6, armv5te, armv5e,
armv5t, armv5, armv4t, armv4, armv3m, armv3, armv2a, armv2

ARM3 shouldn't be a problem :)

[piglet]

tufty vs DavidS, round 1. First to prove smoke-blowing, or a knock out wins.

/me books a seat at the front.

Seconds out....

[Ravenous]

tufty vs DavidS, round 1.

/me books a seat at the front.

Why book a seat, when you can see the same match (and the same result) almost every day round here?

(Ducks out of the way very quickly.)

[DavidS]

Please show some proof of this, or I'll assume you're blowing smoke. A good proof would be a decent-sized piece of modern, portable, self-contained C or C++ code (preferably both), compiled to ELF format. Please feel free to max out the optimisation. I'll take the time to build the latest gcc and llvm suites and provide comparisons.

Ok what would you recomend? Something that is ANSI C complient (Remember that the last ANSI C to date is C 99, C11 is ISO only not ANSI), or uses the level of C++ suppoerted by Norcroft. This means also something that does not use any of the Propritary GCC extensions (copyed by many other compilers still not part of the base standard).

Try this for size : https://github.com/humppa/tiraes

Small enough for us to easily tear the results apart, complex enough to give the optimisers something to go on. Compile for 1176jzf-s (the Pi's processor) if you can, otherwise tell me what processor you want to go for.

Ok setting aside other project for a few to do this . And we will see which is smaller.

And ok I will do it as an ELF. I do not understand the advantage if using C as there is nothing extra that AOF/AIF does not cover. If you would like I could also give a stab at a GCC Compile using GCC 4.1.2 on RISC OS.

ELF means that we have tools to play with the results. I don't have anything to play with AIF or AOF.

Fair enough. Do you mind if I include an AIF? I do have the tools to dicect those though no tools for ELF.

gcc 4.1 could be interesting, although it's waaaaaaay behind the cutting edge. I'm currently at 4.6.2, and even that's significantly out of date (gcc is currently at 4.8.2)

Well so far no one has ported anything newer to RISC OS.

Though RISC OS used to be the ONLY OS for the ARM CPU

And CFront used to be the only C++ compiler. Times change.

Touche. And Linux used to be a small hobby OS writen by a student and only intended to work on the x86. How times change.

Oh, and from the platform options help in gcc 4.6.2 :

Known ARM CPUs (for use with the -mcpu= and -mtune= options):
cortex-m0, cortex-m1, cortex-m3, cortex-m4, cortex-r4f, cortex-r4,
cortex-a15, cortex-a9, cortex-a8, cortex-a5, arm1156t2f-s, arm1156t2-s,
mpcore, mpcorenovfp, arm1176jzf-s, arm1176jz-s, arm1136jf-s, arm1136j-s,
arm1026ej-s, arm926ej-s, fa726te, fmp626, fa626te, fa606te, iwmmxt2, iwmmxt,
xscale, arm1022e, arm1020e, arm10e, arm968e-s, arm966e-s, arm946e-s, arm9e,
arm1020t, arm10tdmi, ep9312, arm940t, arm922t, arm920t, arm920, arm9tdmi,
arm9, arm740t, arm720t, arm710t, arm7tdmi-s, arm7tdmi, fa626, fa526,
strongarm1110, strongarm1100, strongarm110, strongarm, arm810, arm8,
arm7dmi, arm7dm, arm7m, arm7500fe, arm7500, arm7100, arm710c, arm720,
arm710, arm700i, arm700, arm70, arm7di, arm7d, arm7, arm620, arm610, arm600,
arm60, arm6, arm3, arm250, arm2

Known ARM architectures (for use with the -march= option):
iwmmxt2, iwmmxt, ep9312, armv7e-m, armv7-m, armv7-r, armv7-a, armv7,
armv6-m, armv6t2, armv6zk, armv6z, armv6k, armv6j, armv6, armv5te, armv5e,
armv5t, armv5, armv4t, armv4, armv3m, armv3, armv2a, armv2

ARM3 shouldn't be a problem

Interesting, Have you actualy tried the ARMv3 target? I had read that GCC no longer supported it, though I would be glad to be proven wrong on that one.

[DavidS]

tufty vs DavidS, round 1.

/me books a seat at the front.

Why book a seat, when you can see the same match (and the same result) almost every day round here?

(Ducks out of the way very quickly.)

Maybe this time we will get a reasonable result. Will tell you in a few.

Right now I am reinstalling the DDE on my RPi so I can compie this, after making a compile scrpt (I dislike AMU [AMU is the make util in the DDE]). I do almost nothing but assembly so have not had use of the DDE in a long time.

[DavidS]

@Tufty:
Two things:
FIRST:
Do you know what the ANSI C equilivelents are to <unistd.h>, <err.h>, <sys/time.h>, <getopt.h>?
As well as ANSI C equilivents for the functions getopt(),optarg(),errx(),err()?
Or at least good enough descriptions of thes to implement using Macros?

You would chose something that is non portable outside of unixons : ) .

SECOND:
Set your compiler for ARMv5.

[tufty]

Oh, my bad.

I've created a github repository containing one of my favourite toy lisp interpreters (lisp2 from femtolisp). It's totally standalone, and doesn't use anything outside of ansi C. Doesn't do any floating point, though, if you have any ideas for that I'd be more than willing to add more test cases. If you have a github account, let me know and I'll give you commit access (I've added branches for the various compilers).

If anyone has access to the official ARM compiler and wants to let it rip, I'd be interested too.

[edit]Doesn't help if I forget to put a link up : https://github.com/tufty/compiler-test

[DavidS]

@tufty:

Ok I will clean that up. I am assuming that it is C11 based on the errors so at least I should be able to clean it up to compile.

The errors are:

Code: Select all

Norcroft RISC OS ARM C vsn 5.70 [12 Oct 2012]

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 49: Warning: Non-ANSI #include <sys.types.h>

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 49: Serious error: #include file <sys.types.h> wouldn't open

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 50: Error: declaration lacks type (assuming 'int'): 'u_int32_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 50: Error: expected ';' or ',' - inserted ';' before 'value_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 50: Error: declaration lacks type (assuming 'int'): 'value_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 51: Error: declaration lacks type (assuming 'int'): 'int32_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 51: Error: expected ';' or ',' - inserted ';' before 'number_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 51: Error: declaration lacks type (assuming 'int'): 'number_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 54: Error: 'struct <Anon253_line_53>' has no members

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 54: Serious error: expected '}' - inserted before 'value_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 54: Serious error: type disagreement for 'value_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 54: Serious error: duplicate definition of 'value_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 54: Error: expected ';' or ',' - inserted ';' before 'car'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 54: Error: declaration lacks type (assuming 'int'): 'car'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 56: Serious error: Expecting <declarator> or <type> but found '}'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 56: Error: expected ';' or ',' - inserted ';' before 'cons_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 56: Error: declaration lacks type (assuming 'int'): 'cons_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 129: Serious error: #include file "flutils.c" wouldn't open

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 131: Error: 'struct _readstate_t' has no members

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 131: Serious error: expected '}' - inserted before 'ltable_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 131: Error: expected ';' or ',' - inserted ';' before 'labels'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 131: Error: declaration lacks type (assuming 'int'): 'labels'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 134: Serious error: Expecting <declarator> or <type> but found '}'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 134: Error: expected ';' or ',' - inserted ';' before 'readstate_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 134: Error: declaration lacks type (assuming 'int'): 'readstate_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 135: Error: linkage disagreement for 'readstate_t' - treated as 'extern'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 135: Error: declaration lacks type (assuming 'int'): 'readstate_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 135: Error: expected ';' or ',' - inserted ';' before '*'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 135: Error: declaration lacks type (assuming 'int'): 'readstate'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 147: Serious error: illegal left operand to '->'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 148: Serious error: illegal left operand to '->'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 149: Serious error: illegal left operand to '->'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 173: Error: declaration lacks type (assuming 'int'): 'cons_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 173: Error: expected ';' or ',' - inserted ';' before '*'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 173: Error: declaration lacks type (assuming 'int'): 'tocons'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 173: Serious error: Illegal types for operands: '&'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 173: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 173: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 173: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 173: Serious error: expected ';' after command - inserted before '0'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 173: Warning: implicit return in non-void function

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 174: Serious error: Illegal types for operands: '&'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 174: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 175: Error: declaration lacks type (assuming 'int'): 'number_t'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 175: Error: expected ';' or ',' - inserted ';' before 'tonumber'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 175: Error: declaration lacks type (assuming 'int'): 'tonumber'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 175: Serious error: Illegal types for operands: '&'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 175: Serious error: attempt to apply a non-function

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 175: Serious error: attempt to apply a non-function

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 175: Serious error: expected ';' after command - inserted before '0'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 187: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 215: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 216: Warning: implicit return in non-void function

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 236: Error: undeclared name, inventing 'extern int mk_bitvector()'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 236: Error: '=': implicit cast of non-0 int to pointer

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 238: Error: undeclared name, inventing 'extern int ltable_init()'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 240: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 241: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 251: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 251: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 260: Error: undeclared name, inventing 'extern int c'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 260: Warning: no side effect in void context: '*'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 264: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 264: Serious error: expected ';' after command - inserted before 'curheap'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 264: Warning: no side effect in void context: <variable>

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 266: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 267: Warning: implicit return in non-void function

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 272: Error: undeclared name, inventing 'extern int first'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 272: Warning: no side effect in void context: '*'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 275: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 275: Serious error: expected ')' - inserted before 'curheap'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 275: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 275: Serious error: expected ')' - inserted before 'lim'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 275: Serious error: expected ';' after command - inserted before 'lim'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 275: Warning: no side effect in void context: <variable>

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 275: Serious error: expected ';' after command - inserted before ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 275: Serious error: <command> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 277: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 277: Serious error: expected ')' - inserted before 'curheap'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 277: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 277: Serious error: expected ')' - inserted before 'lim'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 277: Serious error: expected ';' after command - inserted before 'lim'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 277: Warning: no side effect in void context: <variable>

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 277: Serious error: expected ';' after command - inserted before ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 277: Serious error: <command> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 281: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 281: Serious error: expected ';' after command - inserted before 'curheap'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 281: Warning: no side effect in void context: <variable>

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 283: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 284: Warning: implicit return in non-void function

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 297: Serious error: Illegal types for operands: '&'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 302: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 302: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 302: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 303: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 303: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 307: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 307: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 308: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 308: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 308: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 308: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 308: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 309: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 309: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 310: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 310: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 312: Serious error: Illegal types for operands: '&'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 332: Error: undeclared name, inventing 'extern int rs'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 332: Warning: no side effect in void context: '*'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 340: Error: '=': implicit cast of pointer to 'int'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 342: Serious error: Illegal types for operands: '->'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 343: Serious error: Illegal types for operands: '->'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 343: Serious error: Illegal types for operands: '->'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 344: Serious error: Illegal types for operands: '->'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 366: Error: undeclared name, inventing 'extern int bitvector_resize()'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 366: Error: '=': implicit cast of non-0 int to pointer

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 469: Warning: no side effect in void context: <variable>

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 469: Serious error: expected ';' after command - inserted before 'x'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 469: Error: undeclared name, inventing 'extern int x'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 469: Warning: no side effect in void context: <variable>

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 499: Error: undeclared name, inventing 'extern int u8_fgetc()'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 501: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 512: Warning: implicit narrowing cast: '='

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 513: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 533: Warning: implicit narrowing cast: '='

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 540: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 571: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 571: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 571: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 571: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 572: Serious error: Illegal types for operands: '&'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 573: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 573: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 578: Serious error: illegal left operand to '->'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 582: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 582: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 588: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 588: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 597: Warning: no side effect in void context: 'unary *'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 629: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 629: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 630: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 630: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 630: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 630: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 631: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 631: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 631: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 631: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 631: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 631: Serious error: <expression> expected but found ')'

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 631: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 631: Serious error: <cast>: cast to non-equal 'value_t' illegal

"SDFS::RISCOSpi.$.Download.TMP.compiler-test-master.c.lisp2", line 634: Fatal error: Too many errors

Compilation abandoned.

Also as to GITHub, I will not be able to upload there as no one has got GIT working on RISC OS yet.

[Paeryn]

It's not C11 (it compiles with std=c99), those errors are from not having u_int32_t and int32_t defined, they're defined in another header that <sys/types.h> includes, but you don't seem to have that.
Change #include <sys/types.h> to #include "lisp2.h" as that defines them (and isn't otherwise referenced).

Also on line 128 it tries to #include "flutils.c" but the file on github is flutils.inc so that needs changing too.

[tufty]

Nah, it's not C11. I doubt it was originally anything more than c89, to be honest.

I've been on a building site all day, haven't had time to reply. Still, here goes :

Looks like you've got 2 problems there:

1 - lack of <sys/types.h> (which is POSIX, dammit)
2 - I'd put a few ugly patches in after my initial commit to make it easier to compile, not least of which was including flutils.inc (was flutils.c), which you appear to be missing.

I've just patched it a bit more, it's now no longer reliant on <sys/types.h> - totally ansi compliant. You should be able to re-download and compile with no trouble.

Cheers

Simon

[DavidS]

Atached are two Zip files one containing the source + Binaries optimized for speed and optimized for size. The linkable object included is optimized for size.

The two AIF files lisp2OSize, and lisp2OSpeed are the final executables.

The second archive contains text files that are dumps of the AOF optimized for size and the AOF optimized for speed. I chose to dump the AOFs as this gives you the symbol table as well, the AIFs do not have a symbol table.


Sorry no elf, I had to hand link to create an elf, and do to my lack of regular use of C I ended up not knowing what to omit from the libs so the ELF was to big to post. Sorry ELF is not normally used in RISC OS unless using gcc.

Though this is why I provide the dumps so you can compare the output, since you say you do not have any AOF/AIF tools.

[tufty]

Okay, quick reply.

Just built a bunch of linkable objects (been having trouble building shared binaries, as I don't have a dynamically linkable libc to hand - this makes the executables "phat")

Haven't tooled about with lower-level gcc optimisation stuff, just used the "stock" size and speed optimisations, -Os and -O3.

I've attached a zip with the binaries (from gcc 4.6.2, we have 1176jzf-s, ARMv5 and ARMv2, and a single binary from llvm 3.2 with the optimizer cranked to the max). Obviously, these are ELF object files, if you have tools to play with them

Sizes as follows:

Code: Select all

insurgent:compiler-test simon$ ls -ltr
total 244
-rw-r--r-- 1 simon 501   149 Nov 13 08:11 README.md
-rw-r--r-- 1 simon 501  2663 Nov 13 19:48 flutils.inc
-rw-r--r-- 1 simon 501 43219 Nov 13 19:49 lisp2.c
-rw-r--r-- 1 simon 501  1209 Nov 13 21:51 Makefile~
-rw-r--r-- 1 simon 501  1237 Nov 13 21:54 Makefile
-rw-r--r-- 1 simon 501 13844 Nov 13 21:55 lisp2-Os-gcc462-1176.o
-rw-r--r-- 1 simon 501 13768 Nov 13 21:55 lisp2-Os-gcc462-armv2.o
-rw-r--r-- 1 simon 501 18956 Nov 13 21:55 lisp2-O3-gcc462-1176.o
-rw-r--r-- 1 simon 501 13836 Nov 13 21:55 lisp2-Os-gcc462-armv5.o
-rw-r--r-- 1 simon 501 18884 Nov 13 21:55 lisp2-O3-gcc462-armv2.o
-rw-r--r-- 1 simon 501 18948 Nov 13 21:55 lisp2-O3-gcc462-armv5.o
-rw-r--r-- 1 simon 501 54432 Nov 13 21:55 lisp2.ir
-rw-r--r-- 1 simon 501 18800 Nov 13 21:55 lisp2-clang32.o

At a first glance, looks like gcc set for size beats norcroft by about 3.5k (13884 bytes vs 17264 in your zip). For speed, it's a bit bigger than the equivalent norcroft executable. That's for an out-of-date gcc (4.6.2, as opposed the current 4.8.mumbledy). llvm/clang is a bit odd, there's no explicit size optimisation, although I could probably play with the lower level optimisations to achieve it. As it stands, it produces slightly smaller object code than gcc optimized for speed, but my install is a bit out of date - this probably (as in, I'm guessing) hurts llvm more than gcc as llvm/arm is a very immature platform.

Obviously, there may be a bit of slack one way or another due to the fact these are object files, not fully linked executables, what sizes do you get for pre-linkage object files?

I'll dump some assembler tomorrow, off to bed right now.

Simon

[tufty]

clang binary attached, bloody forum software only allows 3 attachments.

[DavidS]

The prelinked Object file is 19960 bytes though that is for a AOF which I am not sure how compares to an ELF. I find it interesting that the CLang object that you provide links (using CC through translation to AOF(Translation done by Link)), to an AIF that is over 20KB (slight veriation depending on options). And I have to use gcc Libraries to get it to link. Also the AOF is notacably larger than the ELF.

And if I link your elf objects using gcc the objects are a lot biger (from 24KB to 40KB depending on options). Remember that in RISC OS the final AIF includes the needed libs.

With Norcroft the final executable AIF is smaller than the AOF.

[DavidS]

I have not yet tryed with LCC, as that would require firing up a RiscPC.

[DavidS]

Oh goodie it looks like LCC will run on the RPi .

Now I am off to find the CD.

[tufty]

Okay, some side-to-side code comparison. Take a very simple function, ltable_init()

Code: Select all

typedef struct {
    size_t n, maxsize;
    unsigned long *items;
} ltable_t;

void ltable_init(ltable_t *t, size_t n)
{
    t->n = 0;
    t->maxsize = n;
    t->items = (unsigned long*)malloc(n * sizeof(unsigned long));
}

Norcroft's version:

Code: Select all

  MOV      r12,sp
  PUSH     {r0,r1,r4,r11,r12,lr,pc}
  SUB      r11,r12,#4
  CMP      sp,r10
  BLMI     __rt_stkovf_split_small
  MOV      r4,r0
  MOV      r0,#0
  STM      r4,{r0,r1}
  LSL      r0,r1,#2
  BL       malloc
  STR      r0,[r4,#8]!
  LDMDB    r11,{r4,r11,sp,pc}
  MOV      r2,#0
  STR      r2,[r0]
  MOV      pc,lr

gcc version

Code: Select all

ltable_init:
	mov	r3, #0
	stmfd	sp!, {r4, lr}
	mov	r4, r0
	str	r3, [r0, #0]
	str	r1, [r0, #4]
	mov	r0, r1, asl #2
	bl	malloc
	str	r0, [r4, #8]
	ldmfd	sp!, {r4, pc}

You'll note that the norcroft version:
- uses, and thus has to save, far more registers
- makes space on the frame which it never uses
- ends up having to check stack alignment, therefore using conditionals
- saves itself some space by using stm
- sets up a zero return code for a function returning void.

The gcc version
- (almost) minimises register usage
- has obviously done constant folding, which in this case doesn't pay off
- has eliminated the frame, which *does* pay off
- misses an opportunity to use stm / strd to fill in n and maxsize

Neither are perfect, but gcc wins by 24 bytes and isn't going to upset the branch predictor. There's another 8 bytes to be won *easily* from there.

The clang / llvm version is horrible. Here it is, for laughs.

Code: Select all

ltable_init:                            @ @ltable_init
	push	{r11, lr}
	sub	sp, sp, #16
	str	r0, [sp, #8]
	stm	sp, {r2, r3}
	ldr	r0, [sp, #8]
	mov	r1, #0
	str	r1, [r0]
	str	r1, [r0, #4]
	ldr	r0, [sp, #8]
	ldm	sp, {r2, r3}
	strd	r2, r3, [r0, #8]
	ldr	r0, [sp, #4]
	ldr	r1, [sp]
	lsl	r2, r0, #3
	lsl	r0, r1, #3
	orr	r1, r2, r1, lsr #29
	bl	malloc
	ldr	r1, [sp, #8]
	str	r0, [r1, #16]
	add	sp, sp, #16
	pop	{r11, pc}

a larger routine, the garbage collector - gc(). Not going to do a side-by side, but:

Norcroft : 392 bytes
gcc : 300 bytes
llvm : 588 bytes

The llvm versions are huge and stupid, which leaves me to believe llvm is doing some serious magic when going from intermediate representation to object that it's not doing when it goes from intermediate to source. I'm gonna objdump the object file, rather than asking it to spit out assembler, and see if I'm not doing it a disservice.

[edit]No, I'm not. So where the hell is llvm saving space, because it's not much bigger than the speed-optimised gcc or norcroft versions?

[DavidS]

Yes I also had a look last ight before going to sleep. And GCC does win on size, even though it misses a few opertunities to optimize by not using LDM/STM instructions. It is interesting though in that GCC ignores the ACPS32 calling convention so horrably and completely that I am surprized that it does not break anything, though obviously it works.

This seems to be the size difference in most cases is GCC ignoring the ACPS32 calling convention. I will have to look and see if it is possible to make Norcroft do the same and if so I will post the results.

And just for completeness here is the Speed optimized Norcroft version:

Code: Select all

  0x0001c0:  e1a0c00d  .... : MOV      r12,sp
  0x0001c4:  e92dd813  ..-. : PUSH     {r0,r1,r4,r11,r12,lr,pc}
  0x0001c8:  e24cb004  ..L. : SUB      r11,r12,#4
  0x0001cc:  e15d000a  ..]. : CMP      sp,r10
  0x0001d0:  4bffff8a  ...K : BLMI     __rt_stkovf_split_small
  0x0001d4:  e1a04000  .@.. : MOV      r4,r0
  0x0001d8:  e3a00000  .... : MOV      r0,#0
  0x0001dc:  e5840000  .... : STR      r0,[r4]
  0x0001e0:  e5841004  .... : STR      r1,[r4,#4]
  0x0001e4:  e1a00101  .... : LSL      r0,r1,#2
  0x0001e8:  ebffff84  .... : BL       malloc
  0x0001ec:  e5840008  .... : STR      r0,[r4,#8]
  0x0001f0:  e91ba810  .... : LDMDB    r11,{r4,r11,sp,pc}

I was hoping that our comparison would finaly answer which one produces the better result, though it seems only to raise more questions.

[DavidS]

Ok it seems that Norcroft will not let you ignore the ACPS Calling convention. Is there a way to make gcc enforce it?

[DavidS]

@tufty:
I must admit that gcc is looking a lot better than it used to. Also it seems to be doing a good job at effecient register allocation.

Still would like to see it put out correct ACPS32 code. Reason being that not doing so has to break someting sooner or later.

[tufty]

I don't see where gcc is ignoring apcs, to be honest. It saves what it needs to from r4-r12 and keeps the stack aligned correctly. I'd say that Norcroft is being exceptionally over-zealous (particularly in that it's saving r0 and r1 on entry, knowing full well that it's not going to be needing them at the end; r0 and r1 being return value registers, after all). I was assuming a lot of the Norcroft function prologue stuff was due to RiscOS using some ancient ABI.

Oh, and I was wrong about Norcroft checking for stack alignment, it's checking for stack overflow (the giveaway is the name __rt_stkovf_split_small). Of course, by the time it's got there, the damage has already been done, but it is, at least, checking. There's 2 possible reasons why gcc isn't doing the same:

1 - who cares, right?
2 - stack usage of this function is known to be bounded, and can thus be checked at a higher level via flow analysis.

I'd hope it's the second, but I fear it's probably the first.

Don't suppose you've had a chance to let gcc 4.1.6 rip at this, have you? If you run it as follows, you get the annotated assembler spit straight out the back end, no need to piss about with binaries.

Code: Select all

gcc -S -std=c99 -Os -mcpu=arm1176jzf-s -o lisp2.s lisp2.c

[DavidS]

Oh, and I was wrong about Norcroft checking for stack alignment, it's checking for stack overflow (the giveaway is the name __rt_stkovf_split_small). Of course, by the time it's got there, the damage has already been done, but it is, at least, checking. There's 2 possible reasons why gcc isn't doing the same:

1 - who cares, right?
2 - stack usage of this function is known to be bounded, and can thus be checked at a higher level via flow analysis.

Yes Norcroft is doing explicit stack checking as explicit stack checking is required by ACPS, and flow analysis can not catch everything (there is always the possibility that somethint is putting a bunch of stuff on the stack).

The reason for waiting to check is that there should always be a few KB below the stack limit that is unused (ok there are programms that break this rule, though not many).

I'd hope it's the second, but I fear it's probably the first.

Unfortunately it is probably the first.

Don't suppose you've had a chance to let gcc 4.1.6 rip at this, have you? If you run it as follows, you get the annotated assembler spit straight out the back end, no need to piss about with binaries.

You can tell Norcroft to spit out assembler as well. I just did not think of it at the time.

And no I have not had time to fiddle with GCC yet. maybe today.

I have been busy looking through all of my RISC OS software on CDs, and finding some things I had long forgotten about. This is in part to get LCC installed, and in part to find a bunch of 26bit stuff to use for testing .

Though I do now have a working copy of LCC installed as well. Unfortunately the remaining compiler (EasyC) for RISC OS is truely 26Bit only (unless there has been an update that I do not know about).

[DavidS]

Ok here is the GCC output in assembly.

[DavidS]

Now looking at the output of gcc 4.1.2 on RISC OS for the ltable_init function:

Code: Select all

ltable_init:
	@ args = 0, pretend = 0, frame = 0, outgoing = 0
	@ frame_needed = 1, uses_anonymous_args = 0
	mov	ip, sp
	stmfd	sp!, {r4, fp, ip, lr, pc}
	sub	fp, ip, #4
	cmp	sp, sl
	bllt	__rt_stkovf_split_small
	mov	r3, #0
	mov	r4, r0
	str	r3, [r0, #0]
	str	r1, [r0, #4]
	mov	r0, r1, asl #2
	bl	malloc
	str	r0, [r4, #8]
	ldmea	fp, {r4, fp, sp, pc}

We see that it is nearly identical to that produced by your gcc with the difference being that it actualy does stack checking (as required by ACPS-32, as required for ARM Unixens and RISC OS 32bit addressing).

So if we change the comparison to account for Stack checking the results are a bit different. I do think that this is interesting, as stack checking is supposed to be required.

Though I still do not like the ACPS register naming, using R0-R15 is so much simpler, and easier to remember. Who wants to remember sp when R13 is easier, or pc where R15 is simpler, lr while R14 is much better, fp when it is R11, etc.

[tufty]

nearly identical to that produced by your gcc with the difference being that it actualy does stack checking (as required by ACPS-32, as required for ARM Unixens and RISC OS 32bit addressing).

But still manages to be smaller than the Norcroft version, despite being from a compiler that was notorious for producing poor code on ARM, and missing an obvious optimisation (which is also missed by later versions).

gc() also appears to compile to 400 bytes or so, comparable to more recent versions. It appears that gcc hasn't improved that much, at least for the code in question, to be honest - the prologue you're seeing there is, I suspect, a RiscOS specific thing.

I do think that this is interesting, as stack checking is supposed to be required.

No, all that's specified is that, for a given function, stack-limit < sp <= stack-base, sp mod 4 == 0, you can only read or write to sp <= x < stack-base, and, for publicly facing interfaces, sp mod 8 == 0. You only have to guarantee these invariants, not check them every 20 nanoseconds.

Checking for overflow only guarantees the first invariant, and in most cases is utterly unnecessary as stack usage is known to be bounded for a given portion of code. Stack checking in every function prologue is overkill, to say the least. The third invariant is far more dangerous in real world usage, far more troublesome, and yet neither compiler (can) do anything much to force it.