Vs System Shared Memory

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
aquasnake
Posts: 207
Joined: Fri Sep 13, 2019 11:22 pm

Re: Vs System Shared Memory

Post by aquasnake » Fri Dec 11, 2020 5:40 pm

Continue with my kite flying

Assert is usually used to interrupt code execution due to errors under certain circumstances (at least in my familiar mobile phone system).

So assert is prone to ambiguity (although I'm not a native English speaker). Generating an interrupt source is easier to understand with "fire / trigger"

I don't mean assert can't be used, but the term is so specialized that it confuses beginners

Oziphantom
Posts: 1074
Joined: Tue Feb 07, 2017 2:03 am

Re: Vs System Shared Memory

Post by Oziphantom » Fri Dec 11, 2020 11:47 pm

aquasnake wrote:
Fri Dec 11, 2020 5:11 pm
It is not only in the cc65 scenario to avoid compiler optimizing access to volatile variables.

Insert a meaningless self assignment statement to avoid compiler optimization from looking stupid, if you have any questions about it, it means that you have too little knowledge

In fact, I see this in arm code, such as in the mobile phone system.

This is a common phenomenon of C compiler(rather, it's the behavior of the optimizer), not a feature of cc65.
Never write C code against the compiler, that is just asking for it. And will lead you to pain.
ARM code is different and the compiler will add dummy operations to either
align code such as for branch targets
add a dummy instruction to avoid a pipeline stall
to align code when switching instruction sets

writing 6502 code to put a dummy stall because it just so happens that at the moment in the current version of the compiler ; is not a feature its a flaw, its coding against the compiler and will break eventually or across systems and across other compilers.
aquasnake wrote:
Fri Dec 11, 2020 5:40 pm
Continue with my kite flying

Assert is usually used to interrupt code execution due to errors under certain circumstances (at least in my familiar mobile phone system).

So assert is prone to ambiguity (although I'm not a native English speaker). Generating an interrupt source is easier to understand with "fire / trigger"

I don't mean assert can't be used, but the term is so specialized that it confuses beginners
Assert can interrupt code or it can just output a msg, depends on the architecture and privilege levels and if a debugger is attached. However what ASSERT actually does is "validate that this is true", i.e it asserts it. The word has nothing to do with interrupting, and a C keyword has nothing to do with a hardware description of a register.

User avatar
Jarhmander
Formerly ~J-@D!~
Posts: 519
Joined: Sun Mar 12, 2006 12:36 am
Location: Rive nord de Montréal

Re: Vs System Shared Memory

Post by Jarhmander » Sat Dec 12, 2020 7:35 am

The self-assignment itself looks incredibly stupid. Never, ever did I have to resort to a workaround that stupid (yes, I *did* have to use stupid workarounds at times, because for example the XC8 compiler did *really* stupid things). Yes, depending on the compiler/platform, I saw the generated code isn't exactly good on some compilers, but it is correct, even with volatile register accesses. Incidentally, all the compilers I used honored the volatile keyword. Really, the big issue is that volatile has no effect on cc65, and the kind of problems discussed here could all be solved.
((λ (x) (x x)) (λ (x) (x x)))

User avatar
rainwarrior
Posts: 8000
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Vs System Shared Memory

Post by rainwarrior » Sat Dec 12, 2020 5:26 pm

aquasnake wrote:
Fri Dec 11, 2020 5:11 pm
Insert a meaningless self assignment statement to avoid compiler optimization from looking stupid, if you have any questions about it, it means that you have too little knowledge

In fact, I see this in arm code, such as in the mobile phone system.

This is a common phenomenon of C compiler(rather, it's the behavior of the optimizer), not a feature of cc65.
It's very common to see tweaks made to code to make the compiler generate better code, even ones that look a little silly (and especially on low-rent compilers), but there's a big difference between making correct code faster, and fixing broken code generation.

I simply would not accept such and absurd and semantically meaningless added statement like proof = proof as a solution for the latter case unless extremely desperate. I might be okay with it if it was only to make it faster.

If you write code and it doesn't do what it says, there is a problem with the compiler. If the compiler can't be fixed, you should find a way to work around the problem in a way that the code still says what it means. In this case, the best suggestion I can make is to use assembly for this specific task, because it's a lot more reliable. The cc65 toolchain is pretty good at integrating assembly and C code anyway!


This has got in the back of my mind a bit of brainstorming about how volatile might be fixed in cc65. I think the volatile information can be known to the optimizer (and it looks like it might even be stored per-instruction already), but to make it work I'd have to review every optimization operation (there's probably more than 100 of these) add a small amount of code to any that might eliminate a load or store. I'll put it on my list of things to investigate, but it'll probably take a lot of time (and care) to sort out, so probably won't happen soon.

Post Reply