Author
Topic: OS/4 (technical details only) (Read 27265 times)

I'll test tomorrow, it's bedtime here.Wlink claims it can link win32 and OMF object code. Whether it'll work for OS/2 binaries remains to be seen.Xfree86 actually used ELF code and included an ELF loader to use Linux modules. Needed GCC-ELF etc to build it.Did NASM produce 32 bit OMF without -f? According to the docs, it will use the native object format but I'd expect 16 bit.

; NOTE: This section is out of sync with x264, in order to keep supporting OS/2%ifidn __OUTPUT_FORMAT__,obj %define .text TEXT32 SECTION .text align=4 public use32 FLAT class=CODE%endifit should avoid altering 118 .asm files and remove "text CODE AUTO"Better to keep this after definition of SECTION_RODATA macro

; NOTE: This section is out of sync with x264, in order to keep supporting OS/2%ifidn __OUTPUT_FORMAT__,obj %define .text TEXT32 SECTION .text align=4 public use32 FLAT class=CODE%endifit should avoid altering 118 .asm files and remove "text CODE AUTO"Better to keep this after definition of SECTION_RODATA macro

Ok, that was what was needed. New zip uploaded to Bitbucket, replacing old upload. Map files in zip. David, please test.I'll attach the latest diffs. Still have to solve the mangle prefix, perhaps by adding an option to configure.

Only the FIRST variable in the section is aligned to the desired alignment.The others need to be aligned manually.

Lars,

ff_cos_32 defined in C, what is defined in asm right now is aligned ok

Really ? I could see various variables that were only aligned to 16 bytes (typically it was a sequence of 4 * 4 bytes). If these are only accessed by SSE code then everything is fine but if you pass these to AVX code then you will experience a trap.

Really ? I could see various variables that were only aligned to 16 bytes (typically it was a sequence of 4 * 4 bytes). If these are only accessed by SSE code then everything is fine but if you pass these to AVX code then you will experience a trap.

Interesting to see what do you mean ? (var names)Vars in asm files are defined in 3 ways:SECTION_RODATA (equ align 16)SECTION_RODATA 32SECTION_RODATA 64so, not all of them have to be aligned 32 or 64.However, now all asm sections are aligned 256.

The whole thing is frustrating. This code has been around and works fine on other platforms, so it has to be problem with our platform, rather nasm or GCC. BTW, I'm currently using GCC 5.5.0 as Paul did some more alignment fixes compared to 4.9.2. I've also switched to building Mozilla for the same reason.One possibility I guess is that GCC is screwing up with -O3.

We'll try a version built with -O2. David could you test the build with -O2 in the zip name? Thanks

Dave

I tried it and it still traps.

Right now the ArcaOS kernel does not appear to support AVX, so there is no crash when watching video The OS/4 standard kernel does support AVX and that is when the problem appears. The noAVX version of the OS/4 kernel does not crash when playing videos either.