Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Lars

Pages: [1] 2 3 ... 68
Programming / Re: Building Qt5
« on: November 27, 2022, 12:24:46 pm »
Anyways. even for the later W4 kernels, OS support for SSE is in effect (I tried it and nothing crashed) and since we have 2022, that is sufficiently reliable information to build upon.

Sure. You even can try to build AVX branch - since you have a good way to detect an OS support for it. ;)

Obviously, gcc supports automatic vectorization from C/C++ code but VAC and Watcom compilers do not. Since I never use gcc, I always have to hand code vectorization in assembler (which I do seldomly enough).
I don`t feel like handcoding a SSE version and a AVX version. The speedup with SSE for suitable core functions, compared to using general purpose registers, is already a factor of typically 16 (when using all 8 available XMM registers under 32-bit code) or even much higher, depending on data type (byte, word, dword, qword, single precision float, double precision float).

Programming / Re: Building Qt5
« on: November 26, 2022, 05:24:15 pm »
You are right, that is the easiest and most straightforward way to detect OS support for AVX.
Unfortunately, there is nothing comparable to detect OS support for SSE (that is, CR4.OSFXSR being set instead of CR4.OSXSAVE being set). Looks like Intel never thinks any farther than up to the next corner.

Anyways. even for the later W4 kernels, OS support for SSE is in effect (I tried it and nothing crashed) and since we have 2022, that is sufficiently reliable information to build upon.

I see that you have ISA bus and S3 card. If you can find any documentation on it, look for jumpers that have influence on signal timing. With OS/2 you will always have to go with default timings, never use any "performance tweak" crap.

turn off BIOS shadowing. That is something that was relevant for DOS as it made extensive use of the BIOS.
And I seem to remember that that could lead to timing issues, also with newer kernels.
Then I can remember from long time ago that I had to rejumper a setting on an ET4000 ISA graphics card but I guess you should not have that kind of problem as you have MCA bus, correct?

Programming / Re: Building Qt5
« on: November 25, 2022, 03:07:32 pm »

Used to see some software that checked for OS SSE support, looking I can't find much besides things like this from flac's changelog, (1.2.0)
Code: [Select]
* flac:
    * Added runtime detection of SSE OS support for most operating systems.
Googling, I found this,
Remember that most versions of OS/2 did not support SSE so if someone installs your USBWAVE.DLL on Warp v4 or older, I assume it will crash.

Possible. My hope would be that the most recent W4 kernels (10.104a and the AN kernel versions) will also support save/restore SSE state. After all, we're in 2022. But now that you are mentioning it, I have a partition that I can start with the W4 kernel. Let's see what happens.

Thanks for the link. They are taking a trick to check for OS support (checking for and catching (if necessary) an exception). Very instructive.

Programming / Re: Building Qt5
« on: November 24, 2022, 02:56:36 pm » the registers during context switches. If this happens or the OS/4 kernel is used, these programs crash.

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.  :)

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 ?


Programming / Re: Building Qt5
« on: November 23, 2022, 09:53:13 am »
It's a mix of problems.

1) The compiler needs to properly align data to be loaded into an XMM (SSE) or YMM (AVX) or ZMM (AVX512)  register (at least for performance reasons but some instructions will also lead to a trap if a memory operand does not align on a 16-byte boundary (for SSE), 32-byte boundary (AVX) or 64-byte boundary (AVX52)).

2) an OS needs to support SSE/AVX/AVX512 context save and restore when switching from one application to another.

Regarding 2) , OS/2, eCS and ArcaOS only support SSE context save (FXSAVE, FXRSTOR: 128 bit registers) but OS/4 also supports AVX/AVX512 context save (XSAVE,XRSTOR: 128 bit and 256 bit and 512 bit registers).

So, the safest thing is to never use AVX/AVX512. That will ensure that you can run your SW on OS/2, eCS, ArcaOS and also on OS/4.

If I am wrong, someone please correct me. Personally, I can say that SSE can safely be used (with memory operands 16-byte aligned where necessary) as I did so in the past and I am running eCS.

Multimedia / Re: playing/convert AIFF and AIFC files: interest anyone ?
« on: November 10, 2022, 04:45:57 pm »
The reason I was developing an IOProc is so that you can just double click a sound file to have it play (you do not need an application). Plus, if translation works both ways, you can convert to/from AIFF and AIFC respectively.

I would not know why AIFF would sound any better compared to WAV, provided the very same sample rate and bit depth is chosen (and the very same analog sound source material, of course). The data is exactly the same in both cases (it's plain PCM data). WAV saves it as little endian, AIFF saves it as big endian.

Multimedia / Re: playing/convert AIFF and AIFC files: interest anyone ?
« on: November 10, 2022, 02:40:32 pm »
Hi David,

.m4a is a different format from AIFF or AIFC, it's sound data compressed with MPEG-4 (and not uncompressed PCM data) and also much newer than AIFF and AIFC. I fear that is above my skill level.

AIFF and AIFC sample sound files can be found here:

That's the files I currently test with.

Multimedia / playing/convert AIFF and AIFC files: interest anyone ?
« on: November 10, 2022, 07:47:40 am »

AIFF and AIFC are sound formats that were invented by Apple (I think) for the original MAC and the Apple IIe in 1989 or so.
They resemble WAV files but all meta/header info and data is saved in big endian format (because the Motorola CPU used back at the time was a big endian CPU).

Because I was bored, I am currently working on an IOProc to transform these files into the standard WAV format that MMPM understands. Currently I can read (play) AIFF files in 8-bit,16-bit,24-bit and 32-bit sample size (the data as such is plain PCM data, that is: uncompressed) and uncompressed AIFC files in 8-bit,16-bit,24-bit and 32-bit sample size. I plan to add support for A-law and Mu-law for AIFC.

In theory, OS/2 should already support AIFF, but the IOProc (aiffproc.dll) is broken in that it only endian converts the meta/header data but forgets to endian convert the sound data ...

Is there any interest in this ? Is there also an interest to transform WAV files to the AIFF and/or AIFC formats ?


Multimedia / Re: Rebuilds of MM Audio Pack
« on: November 05, 2022, 02:13:28 pm »
OS/2 already contains an IOProc for AIFF as well as IFF, it's implemented in aiffproc.dll.

Programming / Re: Query pos. data of a minimized window
« on: November 01, 2022, 10:59:59 pm »

and you might have to force these values with WinSetWindowUShort on minimization, I am not sure.

Multimedia / Re: XHCI and USB Audio perspectives
« on: October 30, 2022, 02:09:07 pm »
I have now uploaded to Hobbes (currently, in "incoming" directory). That contains the updated USBAUDIO and USBAUD2 audio drivers.
For the updated XHCI host controller driver, that's up to AN. I suspect they are going to deliver that with AN 5.1.

Multimedia / Re: updated USB audio drivers (heading for 10.245)
« on: October 29, 2022, 11:10:05 am »
Ok that's interesting, yes there is a USB audio device attached to port 6. Obviously, they "pulled in" the whole USB audio device into the computer and just left that standard headphone jack to attach to. Yes that will only be usable with USB. and because it's an XHCI only system, you need the updated USBXHCD driver.

Multimedia / Re: updated USB audio drivers (heading for 10.245)
« on: October 29, 2022, 11:02:46 am »
An easy way to test: just comment out the USB audio drivers in config.sys and check if it still produces sound...

Pages: [1] 2 3 ... 68