Page 2 of 2
Re: x86 vs ARM (android) integer representation glitch?
Posted: Sun Jun 25, 2017 10:59 am
by Geri
this is not a question of your (or my) oppinion, also of the performance of unaligned memory access is a false dilemma.
i obviously also align everything in my c compiler where i can. back then when i designed the system i had two choice:
-either have complitely unaligned memory access alowed even if it MAY compilcates the underlying hardware or the emulator on some platforms a bit.
-OR use memory as an array of 8 byte integers and have all data type 8 byte long, let the images and text files consume 8x more ram than they should or use extremely difficult and slow tricks to compress them on the fly as one bytes (and having 10-100x slower code in some situations), cripple subleq even more, and break the compatibility with every existing code snippet and lets say goodbyte to common sense.
so as you can see actually you cant choose the second option, so it wasnt actually a question of oppinion, its a question of reality. (on arm it was not so big deal to slide with aligned access as you can have 1/2/whatever byte address access - but from armv7 as we seen they also choosed to slide together with unaligned support in the future. its overally wrong to create impression against unaligned memory access, optimization of the code is a brand new question)
Re: x86 vs ARM (android) integer representation glitch?
Posted: Sun Jun 25, 2017 11:13 am
by simeonz
Intel has some kind of circuitry since Nehalem that eliminates the penalty of misaligned accesses, assuming they do not straddle cache or page boundaries. Which means that if a person is obsessive compulsive, they may use different structure packing for optimal performance for different cpu generations. Having cache line aligned tightly packed structures may end up being faster on newer cpus, but slower on older ones. May not be relevant, but someone may find it interesting.
Re: x86 vs ARM (android) integer representation glitch?
Posted: Sun Jun 25, 2017 12:03 pm
by dozniak
alexfru wrote:
C99, §6.3.2.3 (Pointers), clause 7 wrote:A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned for the pointed-to type, the behavior is undefined.
This is C object pointer alignment rules. They have NO relation to ARM processor data alignment requirements.
Re: x86 vs ARM (android) integer representation glitch?
Posted: Sun Jun 25, 2017 3:14 pm
by alexfru
dozniak wrote:alexfru wrote:
C99, §6.3.2.3 (Pointers), clause 7 wrote:A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned for the pointed-to type, the behavior is undefined.
This is C object pointer alignment rules. They have NO relation to ARM processor data alignment requirements.
Let's back up a bit.
dozniak wrote:Geri wrote:arm cpus cant do unaligned access from c.
how is this even remotely related to C?
I just provided the relevant C standard part, answering the question of how this is related to C. Now you're saying it's not related to hardware requirements. But it clearly is. It's the hardware alignment requirements that are reflected in the language standard. And the requirements aren't honored by the code above. At this point you should either explain your logic (which I doubt you can) or stop saying nonsense irrespective of whether you're trolling us or simply not understanding the matter.
Re: x86 vs ARM (android) integer representation glitch?
Posted: Mon Jun 26, 2017 10:56 am
by Korona
Geri wrote:so as you can see actually you cant choose the second option, so it wasnt actually a question of oppinion, its a question of reality.
No, you're just misusing C. C has the tools to deal with unaligned memory access. You're just not using them. You either have to use memcpy() as in:
Code: Select all
void *p; // Some unaligned pointer.
uint32_t v;
memcpy(&v, some_unaligned_ptr, sizeof(uint32_t));
or access the memory via a char pointer as in:
Code: Select all
unsigned char *p; // Some unaligned pointer.
uint32_t v = (uint32_t)p[0] | ((uint32_t)p[1] << 8) | ((uint32_t)p[2] << 16) | ((uint32_t)p[3] << 24);
Both will work with unaligned addresses and the code will be optimized to decent machine code (i.e. no calls, shifts and logical ors, just some loads) by all major compilers.
Read the C standard and understand what the language is doing before blaming the compiler or the architecture.
Re: x86 vs ARM (android) integer representation glitch?
Posted: Mon Jun 26, 2017 5:41 pm
by Geri
thats wrong, the codes you pasted above will never be optimized into anything especially on arm, it will result devasting speed drop, creating useless result
also i not yet even started to observe what is going on as i had other things to do, lets wait the moment where i will accumulate enough soul power to start raping my spirit by putting usb cables for hours. (until that point even the whole unaligned access is just a theory for the glitch - a very very good theory though)
Re: x86 vs ARM (android) integer representation glitch?
Posted: Tue Jun 27, 2017 7:52 am
by Geri
there were/are multiple issues
1. there is probably a watchdog that killed the app after a few second. this happened due to the fact i didnt rendered anything on the screen and android assumed the app has been crashed. my algo renderers from time to time, but in this case it also has to load the large chunk of file from disk, and it had no chance to render anything before the algo killed it. now i do a rendering after setting up the emulation environment, so the watchdog issue is over, i pushed the crash away to further time point.
2. the new crash is suspiciously at an unaligned memory read (i removed __packed but i will reinsert soon. ).
Re: x86 vs ARM (android) integer representation glitch?
Posted: Tue Jun 27, 2017 8:19 am
by Geri
__packed does not allows aligned access, the crash stayed. another great example of official manuals talking bullshit.
then i have to do it with if-s and long crappy unoptimisable code, how nice.
Re: x86 vs ARM (android) integer representation glitch?
Posted: Tue Jun 27, 2017 10:20 am
by dozniak
alexfru wrote:
I just provided the relevant C standard part, answering the question of how this is related to C. Now you're saying it's not related to hardware requirements. But it clearly is. It's the hardware alignment requirements that are reflected in the language standard. And the requirements aren't honored by the code above. At this point you should either explain your logic (which I doubt you can) or stop saying nonsense irrespective of whether you're trolling us or simply not understanding the matter.
ARM cpus don't do unaligned access by default. Regardless if this is from C or from BASIC. That's my point.
My picking is more at very unfortunate choice of words by some particular individual who can't even write proper English sentences.
Re: x86 vs ARM (android) integer representation glitch?
Posted: Tue Jun 27, 2017 10:23 am
by Geri
i replaced the code to do detect unaligned (if(A&7), if(B&7)) and do it with char reads/writes. its still crashing but i am not sure where, i think i will continue it later. another day wasted.
Re: x86 vs ARM (android) integer representation glitch?
Posted: Tue Jun 27, 2017 10:43 am
by Geri
dozniak wrote:some particular individual who can't even write proper English sentences.
this is not englishfanficwriters.org