Hmm that also sounds interesting. I am going to try that too ;). Besides that I have written my read_aligned & write_aligned templates and now it works without UNALIGNED_MEMORY, doing the very same "fallback" only at the places where memory actually could be unaligned. Performance though is still not fully satisfactory, since its just A LOT of places where those templates need to be used. So maybe your Clang pointer attribute can get things done faster.
On Thu, May 8, 2014 at 3:27 PM, Jukka Jylänki <[email protected]> wrote: > Asking around in #llvm irc, people say there that in Clang a syntax > something like "uint32_t __attribute__((align(1))) *pointer = xxx;" could be > used to signal that deferences through that particular pointer should be > treated as unaligned. That should result in unaligned reference in the LLVM > bytecode, which Emscripten is able to pick up and generate an unaligned > load/store, even when no special link flags are used. That could be worth a > try, e.g. typedeffing/defining a pointer type unaligned_u32_ptr or similar? > > > 2014-05-08 16:20 GMT+03:00 Christoph Husse <[email protected]>: > >> Hmm I don't know :D. I will try it if my current approach fails. I >> notices from what Emscripten reported so far that the CPU emulator I >> am trying to compile conveniently pipes all memory accesses through >> macros that do the little/big endian handling. So basically I am now >> trying to hook a warn&fix template into those macros and hope that >> there are not any other misaligned accesses done except through those >> macros. >> >> On Thu, May 8, 2014 at 3:18 PM, Jukka Jylänki <[email protected]> wrote: >> > Oh, I misread Module.getValue and Module.setValue that they'd do >> > unaligned >> > accesses. Well, what happens if you combine that modification with -s >> > UNALIGNED_MEMORY=1? Are those two incompatible? >> > >> > >> > 2014-05-08 15:48 GMT+03:00 Christoph Husse >> > <[email protected]>: >> > >> >> As this was the initial problem. The application does not work without >> >> UNALIGNED_MEMORY. >> >> >> >> On Thu, May 8, 2014 at 2:47 PM, Christoph Husse >> >> <[email protected]> wrote: >> >> > Well its a nice thought but the issue will most likely be that then >> >> > the application gets broken and doesn't do what it would normally do >> >> > ;). I need the UNALIGNED_MEMORY fix in combination with a >> >> > notification >> >> > for actual unaligned accesses. >> >> > >> >> > On Thu, May 8, 2014 at 2:11 PM, Jukka Jylänki <[email protected]> >> >> > wrote: >> >> >> Hmm, looking at the current code, as a quick manual fix you could >> >> >> try >> >> >> compiling with -s SAFE_HEAP=1, and then going to the output file and >> >> >> editing >> >> >> the generated functions SAFE_HEAP_LOAD and SAFE_HEAP_STORE to just >> >> >> 'console.error()' instead of 'abort()'. Does that work? >> >> >> >> >> >> >> >> >> 2014-05-08 14:39 GMT+03:00 Christoph Husse >> >> >> <[email protected]>: >> >> >> >> >> >>> EWWW!!! >> >> >>> >> >> >>> Looks like I have alignment issues (and well... my code too xD). >> >> >>> >> >> >>> So I have now worked a lot on the sources to have the same types on >> >> >>> all platforms, compile by using a single "cpp" file, etc... And I >> >> >>> also >> >> >>> got the emscripten options like SAFE_HEAP really to work. >> >> >>> After executing the thing with Node.js I see that I have unaligned >> >> >>> reads & writes. using UNALIGNED_MEMORY=1 fixes it but its slow >> >> >>> because >> >> >>> it generates the machinery for all loads/stores while only few of >> >> >>> them >> >> >>> are unaligned. >> >> >>> >> >> >>> Is there a way to use UNALIGNED_MEMORY while at the same time >> >> >>> listing >> >> >>> all the places where it actually encountered an unaligned >> >> >>> load/store? >> >> >>> That would be really helpful because right now I would have to find >> >> >>> an >> >> >>> offending line, recompile, restart, find the next offending line, >> >> >>> etc... This would be extremely time consuimg especially since one >> >> >>> iteration may well take over 5 minutes... >> >> >>> >> >> >>> Any ideas? >> >> >>> >> >> >>> On Wed, May 7, 2014 at 9:31 AM, Jukka Jylänki <[email protected]> >> >> >>> wrote: >> >> >>> > Emscripten/JS is a little endian platform, just like X86, so the >> >> >>> > same >> >> >>> > code >> >> >>> > paths should work for JS and X86. It is ok to test for this at >> >> >>> > runtime >> >> >>> > and >> >> >>> > do different things based on the result. Just make sure that the >> >> >>> > JS >> >> >>> > platform >> >> >>> > correctly takes the little endian path and that should be all >> >> >>> > good >> >> >>> > there. >> >> >>> > >> >> >>> > >> >> >>> > 2014-05-07 9:49 GMT+03:00 Christoph Husse >> >> >>> > <[email protected]>: >> >> >>> >> >> >> >>> >> Okay thanks for that input. Gonna try it today. Maybe SAFE_HEAP >> >> >>> >> was >> >> >>> >> off >> >> >>> >> because I didn't get any output. >> >> >>> >> >> >> >>> >> Besides what you have recommended, I was working on "un-stding" >> >> >>> >> my >> >> >>> >> sources >> >> >>> >> yesterday with success. There are NO standard library headers >> >> >>> >> and >> >> >>> >> also >> >> >>> >> no >> >> >>> >> memory allocations (everything froma static buffer) and no >> >> >>> >> conditional >> >> >>> >> compilation macros... All types are the same size and sign on >> >> >>> >> all >> >> >>> >> platforms >> >> >>> >> now. >> >> >>> >> >> >> >>> >> Only left is the big/little endian thing. Do you know if it is >> >> >>> >> okay >> >> >>> >> to >> >> >>> >> do >> >> >>> >> runtime code switches based on endianess? The code needs to take >> >> >>> >> different >> >> >>> >> paths depending on endianess... Its a very low level CPU >> >> >>> >> emulator, >> >> >>> >> so >> >> >>> >> there >> >> >>> >> is a lot of very platform specific low-level code in it. >> >> >>> >> >> >> >>> >> >> >> >>> >> -- >> >> >>> >> You received this message because you are subscribed to the >> >> >>> >> Google >> >> >>> >> Groups >> >> >>> >> "emscripten-discuss" group. >> >> >>> >> To unsubscribe from this group and stop receiving emails from >> >> >>> >> it, >> >> >>> >> send >> >> >>> >> an >> >> >>> >> email to [email protected]. >> >> >>> >> >> >> >>> >> For more options, visit https://groups.google.com/d/optout. >> >> >>> > >> >> >>> > >> >> >>> > -- >> >> >>> > You received this message because you are subscribed to a topic >> >> >>> > in >> >> >>> > the >> >> >>> > Google Groups "emscripten-discuss" group. >> >> >>> > To unsubscribe from this topic, visit >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > https://groups.google.com/d/topic/emscripten-discuss/tOz2Yc_sLuA/unsubscribe. >> >> >>> > To unsubscribe from this group and all its topics, send an email >> >> >>> > to >> >> >>> > [email protected]. >> >> >>> > For more options, visit https://groups.google.com/d/optout. >> >> >>> >> >> >>> -- >> >> >>> You received this message because you are subscribed to the Google >> >> >>> Groups >> >> >>> "emscripten-discuss" group. >> >> >>> To unsubscribe from this group and stop receiving emails from it, >> >> >>> send >> >> >>> an >> >> >>> email to [email protected]. >> >> >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> >> >> >> -- >> >> >> You received this message because you are subscribed to a topic in >> >> >> the >> >> >> Google Groups "emscripten-discuss" group. >> >> >> To unsubscribe from this topic, visit >> >> >> >> >> >> >> >> >> https://groups.google.com/d/topic/emscripten-discuss/tOz2Yc_sLuA/unsubscribe. >> >> >> To unsubscribe from this group and all its topics, send an email to >> >> >> [email protected]. >> >> >> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Groups >> >> "emscripten-discuss" group. >> >> To unsubscribe from this group and stop receiving emails from it, send >> >> an >> >> email to [email protected]. >> >> For more options, visit https://groups.google.com/d/optout. >> > >> > >> > -- >> > You received this message because you are subscribed to a topic in the >> > Google Groups "emscripten-discuss" group. >> > To unsubscribe from this topic, visit >> > >> > https://groups.google.com/d/topic/emscripten-discuss/tOz2Yc_sLuA/unsubscribe. >> > To unsubscribe from this group and all its topics, send an email to >> > [email protected]. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "emscripten-discuss" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to a topic in the > Google Groups "emscripten-discuss" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/emscripten-discuss/tOz2Yc_sLuA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
