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: 691
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 238 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 244 times
OSDK: 1.70 sec, 13350 bytes
aes256-tab-osdk.tap
aes256 using tables OSDK
(13.04 KiB) Downloaded 254 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 244 times
OSDK: ??.?? sec, 14385 bytes
aes256-tab-osdk.tap
aes256 using tables OSDK
(13.04 KiB) Downloaded 254 times
Unfortunately the encryption fails and the back decryption never ends...
Count this as 'OSDK bug report' :).

User avatar
iss
Squad Leader
Posts: 691
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 5797 times

User avatar
Dbug
Site Admin
Posts: 2738
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: 691
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.

Post Reply