Kyra Zimmer

thanks for the confirmation of the wontfix, and the revelation about developer attitude when people merely ask why a bug could go unnoticed for that long, will likely just fork sccz80 or something. just before i go, you'll note the "strange sense of entitlement" only started after you berated me for having the audacity of merely asking why this bothers nobody else for so long, condescendingly lying about C, embedded C and SDCCman. have a day.

so it's a standard relevant feature and SDCC simply implements neither C nor the referenced "embedded C" despite claims to the contrary and the documentation lies and your proposed "solution" is to keep it like that and fix the documentation to lie slightly less; because implementing the standards one claims (and needs to, to correctly support the hardware one claims) is "not relevant"? yeah no, in that case a more realistic bug fix would be writing an actual C compiler.

so it's a standard relevant feature and SDCC simply implements neither C nor the referenced "embedded C" despite claims to the contrary and the documentation lies and your proposed "solution" is to keep it like that and fix the documentation to lie slightly less; because implementing the standards one claims (and needs to, to support the hardware one claims) is "not relevant"? yeah no, in that case a more realistic bug fix would be writing an actual C compiler.

i would very much disagree there. pointers behaving like pointers is very much "standard relevant", and SDCC defines what _sfr is supposed to mean. especially given the fact SDCC just silently generates the wrong code instead of e.g. failing to compile. can you elaborate as to why you'd think "the standard" (also, which one? :P) is perfectly fine with all pointer accesses ignoring a compiler-defined keyword that just silently does the opposite of its documented behavior? and yes, Z88DK does work...

so 2 releases fixing lots of new bugs and renaming a few unimportant things and generally cleaning up later and current trunk still can't use IO pointers :/ is nobody using this compiler for actual Z80 projects that aren't GB?

not sure how the mcs51 port is supposed to be related to z80 IN/OUT instructions tho?

not sure how the mcs51 port is related to z80 IN/OUT instructions tho

oh yeah i know it makes sense on other platforms, i'm just saying if it's abused as IO on z80 it might as well be abused as an "this will always be highmem" hint on gbz80, but that's an optimizer thing, unrelated to the fact a c compiler that doesn't support half the address space of one of its targets is a pretty big deal