Page 1 of 1

c++

Posted: Wed Oct 05, 2016 12:00 pm
by beamrider
https://www.youtube.com/watch?v=zBkNBP00wJE

Interesting presentation. Could equally apply to the Vic-20. Certainly seems to generate leaner code than CC65.

Re: c++

Posted: Wed Oct 05, 2016 12:40 pm
by groepaz
Certainly seems to generate leaner code than CC65
actually, no it doesnt

Re: c++

Posted: Wed Oct 05, 2016 2:50 pm
by beamrider
so does CC65 support in-lining now?

Re: c++

Posted: Wed Oct 05, 2016 3:07 pm
by groepaz
not really (*) - however what you saw in that video can easily be done in cc65, and it will result in better code than what is shown in that video. remember what they are doing is using a x86 compiler, and then translating x86 code to 6502 - which doesnt work well or efficient at all. actually the whole "lets use 6502 as an example" is pretty misleading, the techniques shown are useful for targets for which an actual c++ compiler backend exists - but their x86-to-6502 translator thing isnt really usable for anything (it even chokes on some simple stuff in the video at some point).

(*) some sort of inlining happens by wrapping function calls into macros, and using eg the VIC structs for accessing registers in a similar way as in that video will result in the same "perfect" lda/sta code.

Re: c++

Posted: Thu Feb 15, 2018 3:39 am
by Linzino
Hi

Why would one use C++ to generate 6502 code other than as a proof of concept?

ANSI C allows object-oriented programming in a more efficient way (though, slightly less elegant), through:
- composition + pointer to structs -> inheritance
- pointer to functions -> virtual methods (sub-type polymorphism)

I use object-oriented programming in my massively 8-bit cross-platform game CROSS CHASE
https://github.com/Fabrizio-Caruso/CROSS-CHASE
You can look at src/item.h and see how I achieve some object-oriented design in a not too complicated fashion.

Fabrizio

Re: c++

Posted: Thu Feb 15, 2018 4:09 am
by beamrider
I never got on with the pseudo OO approach in C. I find the syntactic clutter difficult to read so just stick to shared state and functional decomposition. When in Rome...

Edit: Mike - note the correct usage of C :wink:

Re: c++

Posted: Thu Feb 15, 2018 4:25 am
by Linzino
If you look at my code, you won't see much clutter.
Currently I use very little object-oriented programming. My future code may use more.

Object-oriented programming is a pattern and not something enabled by a language.
Some languages provide syntactic sugar for it (usually at a little cost).
The cost may be too high in some cases (e.g., 8-bit CPUs).

Gnome is written in ANSI C and uses object-oriented programming.

An interesting read:
https://www.amazon.co.uk/Object-Oriente ... B00930I6TK

Re: c++

Posted: Thu Feb 15, 2018 6:45 am
by beamrider
Will take a look when I get chance, but I would suggest that your syntactic clutter will increase along with your use of 'OO' '.

I briefly used C in the 90s to implement objects under Microsoft's COM 'interface' based OO platform where C++ came as a welcome relief.

[That book looks to be out of print by the way]

Re: c++

Posted: Tue Mar 27, 2018 1:46 pm
by Tom
Linzino wrote:Hi

Why would one use C++ to generate 6502 code other than as a proof of concept?

ANSI C allows object-oriented programming in a more efficient way (though, slightly less elegant), through:
- composition + pointer to structs -> inheritance
- pointer to functions -> virtual methods (sub-type polymorphism)
Those techniques aren't more efficient, they're equally efficient. Also they're not the totality, but you could similarly implement the remaining C++ runtime features with equivalent efficiency in C — e.g. dynamic cast.

Even restricting talk to a 6502 though, one might prefer C++ over C for generics. The video is very misleading — compare the "it uses no storage" conclusion to the admission that the 80c86 to 6502 translator is using the zero page to store pretend 80x86 registers — but I think its instinct is correct; the advantage of modern C++ is compiler code generation. E.g. if you use, say, std::sort with appropriate constness on your class's < operator then the compiler can generate sorting code with that operator and class size, and whatever is necessary to move an entry if anything beyond a byte copy, baked right in. Not looked up at runtime.

That said, you've such a finite memory pool that you might prefer that more things were being looked up at runtime. C with completely dynamic dispatch and untyped containers certainly seems to win the memory footprint battle.