x86 vs ARM (android) integer representation glitch?
Re: x86 vs ARM (android) integer representation glitch?
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)
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)
Operating system for SUBLEQ cpu architecture:
http://users.atw.hu/gerigeri/DawnOS/download.html
http://users.atw.hu/gerigeri/DawnOS/download.html
Re: x86 vs ARM (android) integer representation glitch?
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?
This is C object pointer alignment rules. They have NO relation to ARM processor data alignment requirements.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.
Learn to read.
Re: x86 vs ARM (android) integer representation glitch?
Let's back up a bit.dozniak wrote:This is C object pointer alignment rules. They have NO relation to ARM processor data alignment requirements.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.
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.dozniak wrote:how is this even remotely related to C?Geri wrote:arm cpus cant do unaligned access from c.
Re: x86 vs ARM (android) integer representation glitch?
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: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.
Code: Select all
void *p; // Some unaligned pointer.
uint32_t v;
memcpy(&v, some_unaligned_ptr, sizeof(uint32_t));
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);
Read the C standard and understand what the language is doing before blaming the compiler or the architecture.
managarm: Microkernel-based OS capable of running a Wayland desktop (Discord: https://discord.gg/7WB6Ur3). My OS-dev projects: [mlibc: Portable C library for managarm, qword, Linux, Sigma, ...] [LAI: AML interpreter] [xbstrap: Build system for OS distributions].
Re: x86 vs ARM (android) integer representation glitch?
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)
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)
Operating system for SUBLEQ cpu architecture:
http://users.atw.hu/gerigeri/DawnOS/download.html
http://users.atw.hu/gerigeri/DawnOS/download.html
Re: x86 vs ARM (android) integer representation glitch?
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. ).
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. ).
Operating system for SUBLEQ cpu architecture:
http://users.atw.hu/gerigeri/DawnOS/download.html
http://users.atw.hu/gerigeri/DawnOS/download.html
Re: x86 vs ARM (android) integer representation glitch?
__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.
then i have to do it with if-s and long crappy unoptimisable code, how nice.
Operating system for SUBLEQ cpu architecture:
http://users.atw.hu/gerigeri/DawnOS/download.html
http://users.atw.hu/gerigeri/DawnOS/download.html
Re: x86 vs ARM (android) integer representation glitch?
ARM cpus don't do unaligned access by default. Regardless if this is from C or from BASIC. That's my point.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.
My picking is more at very unfortunate choice of words by some particular individual who can't even write proper English sentences.
Learn to read.
Re: x86 vs ARM (android) integer representation glitch?
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.
Operating system for SUBLEQ cpu architecture:
http://users.atw.hu/gerigeri/DawnOS/download.html
http://users.atw.hu/gerigeri/DawnOS/download.html
Re: x86 vs ARM (android) integer representation glitch?
this is not englishfanficwriters.orgdozniak wrote:some particular individual who can't even write proper English sentences.
Operating system for SUBLEQ cpu architecture:
http://users.atw.hu/gerigeri/DawnOS/download.html
http://users.atw.hu/gerigeri/DawnOS/download.html