LSS10999 wrote on 2023-07-09, 14:10:

I'm not sure how relevant SSE context switching would be for DOS, as I don't think DOS has the concept of threads compared to Windows, but I wonder if things like TSRs or INT handlers can be considered as such...

i can not imagime tsr/int/irq handler for dos, which want use sse or avx by any reason...
but even if such hanlders exist (for sample, as part BIOS code), on my think, they must save/restore this context by self.

If any TSR wanted to use them, it would have to be responsible for saving the original contents and restoring them when returning. It's the only sane way it would work.

SSE 1.0 should enable SSE in dos, win31 and windows95:
http://falcosoft.hu/dos_softwares.html#sse
http://falcosoft.hu/sse.zip

NT4.0 SSE:
http://web.archive.org/web/20170825035744/htt … s.cf/nt4sse.zip

MERCURY127 wrote on 2023-07-16, 10:51:

i can not imagime tsr/int/irq handler for dos, which want use sse or avx by any reason...
but even if such hanlders exist (for sample, as part BIOS code), on my think, they must save/restore this context by self.

I'm just asking. Nothing I know of is actually using SSE/AVX at the moment, though the possibility to allow SSE/AVX instructions to be used in DOS programs (if desired) has always been there, since nothing bars you from flipping the necessary CR0 and CR4 bits. I don't know if compilers or assemblers that can target DOS could be configured to actually generate some SSE/AVX instructions so it could be experimented somehow...

jmarsh wrote on 2023-07-16, 11:42:

If any TSR wanted to use them, it would have to be responsible for saving the original contents and restoring them when returning. It's the only sane way it would work.

I agree with this. SSE-aware TSRs will need to handle the saving/restoring of these registers themselves.

I think there are context switching operations everywhere in a multitasking OS. SSE added a few more context-relevant registers that an OS kernel needs to deal with on top of the usual ones that need to be saved/restored, and there's no way for OSes that predate SSE support to know about them without the help of necessary drivers and APIs.

DOS isn't a multitasking OS though - it has no concept of context switching full stop, let alone things like FPU/MMX and SSE state.

LSS10999 wrote on 2023-07-16, 12:08:

I don't know if compilers or assemblers that can target DOS could be configured to actually generate some SSE/AVX instructions so it could be experimented somehow...

I don't know if SSE instructions are even possible in 16-bit code, but as far as 32-bit code is concerned, assemblers typically don't care about the operating system and linkers don't care about single instructions. So you could use a modern assembler like NASM with its support for SSE instructions together with DJGPP's or Watcom's linker to generate exe utilising those instructions.

Azarien wrote on 2023-07-16, 13:29:

I don't know if SSE instructions are even possible in 16-bit code, but as far as 32-bit code is concerned, assemblers typically don't care about the operating system and linkers don't care about single instructions. So you could use a modern assembler like NASM with its support for SSE instructions together with DJGPP's or Watcom's linker to generate exe utilising those instructions.

SSE instructions need to have the necessary CR0 and CR4 bits configured before executing. Otherwise those opcodes will #UD regardless.

I'm not sure if it's possible to perform SSE opcodes in 16-bit code after configuration, but I once did some operations involving 32-bit registers (namely EAX) inside 16-bit code by writing down raw opcodes with "db", and they worked as expected.

I think as long as opcodes are correct for a given program's bitness (16-bit or 32-bit), it'll work regardless of OS. There are some online sites that can help with getting the correct opcode bytes for given instructions.

jmarsh wrote on 2023-07-16, 12:34:

DOS isn't a multitasking OS though - it has no concept of context switching full stop, let alone things like FPU/MMX and SSE state.

I presume the multitaskers built on top of DOS - Windows, DESQview, MS-DOS Shell, PC Tools, etc. - do know about preserving FPU state, and would make a mess of things if you tried to multi-task two applications that used SSE instructions?

doshea wrote on 2023-07-17, 08:24:

jmarsh wrote on 2023-07-16, 12:34:

DOS isn't a multitasking OS though - it has no concept of context switching full stop, let alone things like FPU/MMX and SSE state.

I presume the multitaskers built on top of DOS - Windows, DESQview, MS-DOS Shell, PC Tools, etc. - do know about preserving FPU state, and would make a mess of things if you tried to multi-task two applications that used SSE instructions?

Late DOS-based Windows, such as 98 and ME, do have SSE support, so they will try preserving SSE states as well as others.

Win95 and earlier predate SSE and need the SIMD95 tool (or any other alternative) to enable SSE. However they themselves do not know about SSE and will not try to preserve SSE states, which can lead to issues if more than one thread is doing SSE operations.