Bocco's adventures

Want to talks about games you like, would like to see developed on the Oric, it's here.
User avatar
iss
Squad Leader
Posts: 890
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Bocco's adventures

Post by iss » Thu Aug 15, 2019 11:03 pm

Sizes cc65 vs (osdk):

_playerUpdate 3549 (7581)
_emenyLeftRightUpdate 1414 (3247)
_addObjectInEngine 81 (!?!) (3070)
_animator 1055 (2066)
_enemyUpDownUpdate 828 (1712)
_printKeysScreen 610 (1512)
_input 206 (1376)
_addObject 538 (1216)

Attached are sym+map files.
Attachments
boko-sym-map.zip
(5.9 KiB) Downloaded 42 times

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

Re: Bocco's adventures

Post by Dbug » Fri Aug 16, 2019 5:15 pm

That's a crazy size reduction.

Is it somewhat possible to compile CC65 to assembler source code so I can compare the results with what LCC is generating?
I think Fabrice would be interested :)

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

Re: Bocco's adventures

Post by Chema » Sat Aug 17, 2019 8:28 pm

Crazy and quite unexplainable, if you ask me. I can't see how this can happen, unless everything is implemented as subroutines, with the consequent waste of time.

Other big cuts to code size could be achieved by adding constraints to the compiler. If you don't allow recursion or limit the number or type of the parameters in functions, but I doubt that is the case here.

I am curious indeed :)

User avatar
retroric
Pilot Officer
Posts: 90
Joined: Sun Nov 22, 2009 4:33 pm
Location: Paris, France

Re: Bocco's adventures

Post by retroric » Sun Aug 18, 2019 6:24 pm

Well,

If you look at the code on GitHub, you can see there are quite a lot of functions, many of them taking many parameters, even including "int" parameters for some of them... Yet, cc65 seems to generate code that is both quite compact and fast. On the latter point if would be interesting as well to compare the relative speeds of the game compiled with cc65 and OSDK...

Now, if you look at functions like animator() (in src/engine.c), where the generated code is twice as big for OSDK, you see it is composed mainly of conditionals, dereferencing arrays with pointers, integer computations, and only 4 calls to the same "printBG()' functions, so it looks like the difference between cc65 and lcc65 (OSDK) may not necessarily be in the calling of functions, but maybe rather in the way conditionals, tests, pointer operations and arithmetics is implemented.

Obviously, to be able to see exactly where cc65 is more efficient than lcc65 we would need to be able to compare generated assembly codes, as DBug pointed out..
flag_fr RetrOric, aka laurentd75 flag_uk
            GitHub - RetrOric

User avatar
retroric
Pilot Officer
Posts: 90
Joined: Sun Nov 22, 2009 4:33 pm
Location: Paris, France

Re: Bocco's adventures

Post by retroric » Sat Aug 24, 2019 8:18 pm

Another thought on this:

While searching the forum for some old topics about cc65 to gather some information, I came across this one: Questions to CC65 users

There is a very important piece of info in it, examplified in the first reply by iss in which he demonstrates that cc65 cleverly optimizes calculations involving char types to 8-bit arithmetics, even though the C standard mandates conversion to the int type for all integer calculations, which means calculations using 16-bit arithmetics at least should be used, as this is the smallest acceptable width for the 'int' type in the standard. See for instance this blog post: Deep C: Integer Promotion or this one: Integer promotions in C, and ponder the implications of this rule, especially for computations involving unsigned and signed variables...

Incidentally, I totally ignored this rule in the C standard until I was told by Fabrice F. the maintainer of the lcc compiler for the OSDK, while discussing code generation and optimization and problems I faced when trying to turn my small "Electr'Oric" game demo into a fully-fledged game, soon hitting memory limits for my compiled code. This was a shock to me at the time, because I thought well, what's the use of a C compiler for the 6502 if it generates verbose, unoptimized 16-bit arithmetic code for simple 8-bit calculations?? I also unfortunately discovered, as DBug had advised me, that the way to go to reclaim some memory was to do away with all function parameters and use global variables instead... This provided a huge memory gain, however there was no cure for the "16-bit calculations" problem...

Anyway, to wrap it up, I think this fundamental difference between cc65 and OSDK's lcc for handling 8-bit arithmetics may very well explain some (or even most) of the generated code size reduction between cc65 and lcc...
Last edited by retroric on Sat Aug 24, 2019 8:26 pm, edited 1 time in total.
flag_fr RetrOric, aka laurentd75 flag_uk
            GitHub - RetrOric

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

Re: Bocco's adventures

Post by Chema » Sat Aug 24, 2019 11:48 pm

Wells, both compilers can generate assembly code so it would be nice to compare the output of one or two of those routines...

I can't do that now, I am on holiday :D but shouldn't be difficult.

User avatar
Steve M
Squad Leader
Posts: 533
Joined: Fri Mar 24, 2006 3:33 am
Location: Cumbria, UK
Contact:

Re: Bocco's adventures

Post by Steve M » Sat Aug 24, 2019 11:58 pm

Just seen this game - looks good. :D
Well done with the work so far.

Post Reply