A new well-known compiler

Since we do not have native C compilers on the Oric, this forum will be mostly be used by people using CC65 or the OSDK. But any general C related post will be welcome !
User avatar
iss
Squad Leader
Posts: 694
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: A new well-known compiler

Post by iss » Sat May 10, 2014 1:20 am

Thanks Dbug for the nice (short and meaningful!) list. I'll definitely use it and report back.
Here is one 'real-life' example - aes256 algo :).
aes256-sources.zip
aes256 source files
(5.57 KiB) Downloaded 239 times
Looking in sources:

Code: Select all

file aes256.c @line 25:
#define BACK_TO_TABLES
If it's uncommented the algo obviously uses tables for calculations and the speed is high:
CC65: 1.72 sec, 9503 bytes
aes256-tab-cc65.tap
aes256 using tables CC65
(9.28 KiB) Downloaded 245 times
OSDK: 1.70 sec, 13350 bytes
aes256-tab-osdk.tap
aes256 using tables OSDK
(13.04 KiB) Downloaded 255 times
If the above line is commented (i.e. not using tables)
CC65: 23.63 sec, 9302 bytes
aes256-tab-cc65.tap
aes256 using tables CC65
(9.28 KiB) Downloaded 245 times
OSDK: ??.?? sec, 14385 bytes
aes256-tab-osdk.tap
aes256 using tables OSDK
(13.04 KiB) Downloaded 255 times
Unfortunately the encryption fails and the back decryption never ends...
Count this as 'OSDK bug report' :).

User avatar
iss
Squad Leader
Posts: 694
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: A new well-known compiler

Post by iss » Sat May 10, 2014 1:24 am

Continued ...
TXT - plain text
KEY - encryption key
ENC - encrypted message
TST - test - how the encrypted message should look like
DEC - decrypted plain text (i.e = TXT)
Here is what to expect as proper result:
snapshot.jpg
snapshot.jpg (18.03 KiB) Viewed 5862 times

User avatar
Dbug
Site Admin
Posts: 2744
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: A new well-known compiler

Post by Dbug » Sat May 10, 2014 6:50 am

You wrote CC65, so I guess you are not testing the gcc 6502?
Do you think you could get CC65 to output an assembler source code and attach it as well to your post?

This 9 KB vs 14 KB size different is indeed interesting, looks like CC65 has improved since when we were checking with Jede (more than 10 years ago).

Godzil
Squad Leader
Posts: 758
Joined: Sat May 21, 2011 7:21 pm
Location: Between UK and France
Contact:

Re: A new well-known compiler

Post by Godzil » Sat May 10, 2014 10:15 am

You also didn't tell that gcc wasn't designed for anything that have less than 32bit... There isn't any official 16bit cpu backend..

I cant expect it to make correct code for an 8bit cpu without lots and lots of changes inside and until it's official expect that it can disappear in a second

User avatar
iss
Squad Leader
Posts: 694
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: A new well-known compiler

Post by iss » Sat May 10, 2014 12:46 pm

@Godzil: Good points. I agree with you.

@Dbug: Yes, currently I have OSDK and CC65 working side-by-side. I'm using common Makefile per project, so it's easy to compile everything with both toolchains. And yes, CC65 seams to be actively developped (unfortunately most changes are related to Commodore).
I hope to have GCC as an option soon too, but for now I succeeded only in building the compiler. My checks with dejagnu regression tests are far from the announced on the maintainer's site. I'm waiting his feedback.
Attached is aes256 demo compiled with CC65 with preprocessed files (look for *.c1 files :))
aes256-src+asm.zip
(79.02 KiB) Downloaded 253 times

User avatar
NekoNoNiaow
Flying Officer
Posts: 149
Joined: Sun Jan 15, 2006 10:08 pm
Location: Montreal, Canadia

Re: A new well-known compiler

Post by NekoNoNiaow » Tue Nov 27, 2018 2:26 am

Allow me to resurrect this very interesting thread/topic. ;)

I have been working on optimizing a demo effect written in C these past weeks/months (a few hours at a time) and I have reached a point where further optimizations of the C code do not produce the expected result.
=> The generated code ends up being slower or the same when it should definitely be faster (even accounting for the limited register set of the CPU).

Looking at the assembler output it is clear that the quality of the produced machine code is responsible for the algorithm optimizations not translating into actual results:
  • the code shuffles data back and forth between zero-page-simulated-registers and memory, it looks like it spends more time doing that than actual useful work. ;)
  • the Y register is only used as an index, never as a temporary storage to avoid a Load/Store
  • the X register is used only once in a blue moon and only when the wind blows to the South :D
  • many successive operations are redundant and unnecessary (ex: LDA tmp0; STA tmp0 -> \(ToT)/ )
  • as a consequence of the above the code is much larger than it needs to be
This leads me to think that the topic of switching compilers or enhancing the current one would be worth discussing again. ;)

I see several avenues:
  • Enhancing the current compiler. To some extent that can be done very cheaply by implementing a simple peephole optimizer, these are usually very simple to implement and there are multiple open source implementations to start from (ex: http://aminet.net/package/dev/asm/popt an m68k peephole optimizer written by a friend of mine when I was in College).
  • Offering multiple compiler choice for the OSDK (after all, the current compiler works so there is no need to remove it) by allowing to work with ISS's version of CC65 (or whichever other one that works). (And http://www.6502.org/tools/asm/ lists a lot of possible alternatives, many likely are not maintained anymore though I suppose.)
@ISS, did your attempts to work with CC65 lead you to a result that can be integrated to the OSDK?

Update: Obviously my memory is failing me because there is already a peephole optimizer available (cf viewtopic.php?t=1805#p17427) but it is currently disabled because it is not 100% reliable.
I am updating to the latest OSDK (1.13) and will give a go at fixing it.

User avatar
Chema
Game master
Posts: 2304
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: A new well-known compiler

Post by Chema » Mon Dec 17, 2018 6:18 pm

That would be great indeed!

However, if I remember correctly, the compiler generates fat code mainly because the backend is designed for 16-bit systems (I mean, it is using the standard 16-bit integer size), so it does not optimize things such as small numbers (8-bit), counters and loops. Besides, as the 6502 only has one stack, the C stack frame has to be simulated and passing parameters to functions is also quite slow.

The backend also generates macros which are then substituted using the preprocessor with asm code, with no further optimization, thus the crappy code.

I really think that you need, either some kind of specifically C version for 8-bit processors (with 8-bit integers, for instance, and 16-bit for long integers) and a good compiler, or a totally different language, aimed to generate optimized asm code.

The best thing is, of course, use asm directly for key routines, as Dbug many times suggested. The 6502 asm is quite easy and straightforward when compared to others (68000, 6809 or z80).

Post Reply