OS/2, eCS & ArcaOS - Technical > Programming

Building Qt5

<< < (11/13) > >>

OS4User:

--- Quote from: Dave Yeo on November 23, 2022, 05:51:55 pm ---...store the registers during context switches. If this happens or the OS/4 kernel is used, these programs crash.

--- End quote ---

Small clarification.

Programs crash happens not because of "store the registers during context switches".
It happens because  programs detects AVX support by OS and thus uses AVX branches of  their code.

And as you rightly said, our set (GCC + linker) is not able to  generate correct AVX code. But there is hope.  :)

Dariusz Piatkowski:

--- Quote from: OS4User on November 23, 2022, 06:32:59 pm ---Small clarification.

Programs crash happens not because of "store the registers during context switches".
It happens because  programs detects AVX support by OS and thus uses AVX branches of  their code.

And as you rightly said, our set (GCC + linker) is not able to  generate correct AVX code. But there is hope.  :)

--- End quote ---

OK, the BOLD highlight is mine...and that's also the focus point: so enlighten us, what exactly does that mean? (is someone else working on getting the GCC thing fixed-up for us? I ask b/c AFAIK Paul is the only one who actively maintains and ports the latest releases...sooo....????)

Dave Yeo:
Well, Bitwise has expressed interest in adding Elf support and Paul did some work on it. Turns out that wlink can produce OS/2 executables from ELF objects but has problems with C++ code, or rather symbols, and it is possible that Steven might find time to fix that.

Paul Smedley:

--- Quote from: Dave Yeo on November 24, 2022, 03:38:41 am ---Well, Bitwise has expressed interest in adding Elf support and Paul did some work on it. Turns out that wlink can produce OS/2 executables from ELF objects but has problems with C++ code, or rather symbols, and it is possible that Steven might find time to fix that.

--- End quote ---

Slight correction to the above.... GCC itself doesn't produce a.out or ELF code - it produces assembly; then gas (GNU Assessember) converts that assembler code into object code. It's trivial to compile gas.exe for OS/2 to use ELF format code; but as Dave says, the linker is the problem. wlink works for some cases, but not all.

Then the work would need to go into emxomfld and probably emxexp/emximp to handle things.....

Lars:

--- Quote from: OS4User on November 23, 2022, 06:32:59 pm ---
--- Quote from: Dave Yeo on November 23, 2022, 05:51:55 pm ---...store the registers during context switches. If this happens or the OS/4 kernel is used, these programs crash.

--- End quote ---

Small clarification.

Programs crash happens not because of "store the registers during context switches".
It happens because  programs detects AVX support by OS and thus uses AVX branches of  their code.

And as you rightly said, our set (GCC + linker) is not able to  generate correct AVX code. But there is hope.  :)

--- End quote ---

You are raising an interesting question:

I recently released a new USBWAV.DLL containing 2 IOProcs where it made sense to implement certain things with SIMD instructions (SSE ...).
I hand coded the SIMD code in assembly, using the NASM assembler which also allowed me to force alignment where necessary. But my code only checks if SSE/SSE2/SSE3/SSSE3 is supported by the CPU but it does not check for CR4.OSFXSR flag that indicates that the OS supports SSE context save/restore as I know that OS/2 supports that (for SSE).
Does other SIMD code explicitely check not only for CPU support but also OS support ? And since reading CR4 into a register is only available in Ring 0, so how would application SW (executing in Ring 3) be able to check for that flag ?

Lars

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version