Jump to content

Windows XP/2003 x32 on Modern Hardware FAQ


Mov AX, 0xDEAD

Recommended Posts

Solving BSODs 0xA5(...,  ...,  ...,  ...):
Windows XP/2003 supports only ACPI 1.0b syntax, last generation bioses uses ACPI 2.0+
To support ACPI 2.0 syntax need replace acpi.sys and apply additional patches to avoid known BSODs :

- 0xA5 (0x03, ..., C0140001, ...) missing ACPI 2.0 syntax, 95% solved, solutions:
   1) acpi.sys v.5048, sha1:a09c0d9f6b5cb63192e2cebada56db38d3870b29) from Vista Beta/Longhorn v.5048
      Pro:
    - Has most of ACPI 2.0 syntax opcodes
    - All integers are 64-bit regarding ACPI 2.0 specification
      Cons:
    - beta, compiled for next generation of windows
    - failed implementation of some internal data types, _ValidateArgTypes generates BSOD 0xA5(0x03, xxx, C0140008, yyy)
      Patches:
        - Add pointer to _atDataObj struct for QWord Opcode
          (_OpcodeTable start at .data:00039848, _atDataObj struct at .data:000397A8,
           missing pointer at .data:00039880, dont forget add additional relocs)

   2) acpi.sys v.6666 based on original Windows XP SP3 v.5512 with integrated acpi 2.0 syntax support
      Pro:
    - based on original v.5512, match binary/offsets
      Cons:
    - All integers are still 32-bit, any operations on 64-bit fields/variables will drop high part of QuadWord
   3) acpi.sys compiled from leaked "XP SP1+W2003 RTM" sources

      Pro:
    - allow compile x64 build based on W2003 sources
      Cons:
    - same as v.6666

- 0xA5 (0x11, 0x08, ..., ...) unknow error in _AMLILoadDDB, probably fail after parsing DSDT/SSDT table, solved
     Patch (by Diderius):
    - Ignore status of _AMLILoadDDB in _ACPIInitializeDDB
     (v5512 jl short .text:00036214 => nop, nop)

- 0xA5(0x03, ..., C0140008, ...) DSDT code have operation with unexpected type of arguments, partially solved
    This BSOD probably means some argument has datatype, allowed only in ACPI 2.0
    v6666 & v5048 support only argument datatypes allowed in ACPI 1.0b specification
    Patch:
        - _ValidateArgTypes must always return "OK", even on realy wrong types
          (mov edi, 0xC0140008=>mov edi, 0x00000000 at head of _ValidateArgTypes)

- 0xA5 (0x10006, ..., ..., ...), missing _DIS method for "PNP0C0F"s (PCI Interrupt Link Devices) in DSDT/SSDT table
    Patch (by Daniel_k):
        - Skip looking for PNP0C0F in _DisableLinkNodesAsyncWorker,
          (v5512 call strstr, ..., jz .text:0001BBBD => jmp .text:0001BBBD )

Intel Motherboards specific issues:
1) ACPI BSOD 0xA5 (0x02, ..., ..., ...), error in ACPIRangeValidatePciResources, ACPI vs E820 conflict, solved
     BSOD is generated by DSDT code like this:

     DWordMemory (ResourceProducer, PosDecode, MinFixed, MaxFixed, NonCacheable, ReadWrite,
          0x00000000,         // Granularity
          0x00000000,         // Range Minimum
          0xDFFFFFFF,         // Range Maximum
          0x00000000,         // Translation Offset
          0xE0000000,         // Length
          ,, _Y0E, AddressRangeMemory, TypeStatic)
     ...

     CreateDWordField (BUF0, \_SB.PCI0._Y0E._MIN, M1MN)  // _MIN: Minimum Base Address
     CreateDWordField (BUF0, \_SB.PCI0._Y0E._MAX, M1MX)  // _MAX: Maximum Base Address
     CreateDWordField (BUF0, \_SB.PCI0._Y0E._LEN, M1LN)  // _LEN: Length
     M1LN = M32L /* External reference */
     M1MN = M32B /* External reference */
     M1MX = ((M1MN + M1LN) - One)

     Sometimes M1LN, M1MN, M1MX cannot be calculated properly and this code claim most of memory
    (E0000000 = 3.7Gb) as motherboard resource, this brings to conflict with E820 memory ranges list

    Patch:
    - memory check in ACPIRangeValidatePciResources must always return "OK"
     (v5512 jz short .text:0001E0BB => jmp short .text:0001E0BB)

2) Device Manager show conflict between Video Card and Motherboard resources
 Device IOTR(PNP0C02) claim 255 I/O adresses in range 0xFF00-0xFFFE, this range conflict with Video Card I/O range because vga has limitation to 10Bit I/O decoding. solved, two solutions:
1) Manual patching DSDT table, remove this lines inside method _CRS of IOTR device,  so _CRS will return empty Local0:

               If ((ITS0 == One))
                {
                    ConcatenateResTemplate (Local0, BUF0, Local1)
                    Local0 = Local1
                }

                If ((ITS1 == One))
                {
                    ConcatenateResTemplate (Local0, BUF1, Local1)
                    Local0 = Local1
                }

                If ((ITS2 == One))
                {
                    ConcatenateResTemplate (Local0, BUF2, Local1)
                    Local0 = Local1
                }

                If ((ITS3 == One))
                {
                    ConcatenateResTemplate (Local0, BUF3, Local1)
                    Local0 = Local1
                }

2) Patch acpi.sys with injecting special code to override IOTR template buffer:
    In _Buffer opcode handler replace:

      mov     eax, [ebx+14h]
      mov     ecx, [ebp+arg_0]

    to

      call    Check_IOTR_Buffer
      ...
Check_IOTR_Buffer:
      cmp     eax, 0Ah                         ; eax - size of buffer
      jnz     short Skip
      mov     eax, [ebx+30h]
      mov     eax, [eax+10h]                   ; eax - buffer
      cmp     dword ptr [eax], 00000147h       ; need matching all 10 bytes
      jnz     short Skip
      cmp     dword ptr [eax+4], 0FF010000h
      jnz     short Skip
      cmp     word ptr [eax+8], 0079h            
      jnz     short Skip
      mov     byte ptr [eax+7], 0           ; MAIN ACTION, set i/o range to 0 instead 255

Skip:
      mov     eax, [ebx+14h]
      mov     ecx, [ebp+arg_0]
      ret

 IOTR template defined as:

         Name (BUF0, ResourceTemplate ()
                {
                    IO (Decode16,
                        0x0000,             // Range Minimum
                        0x0000,             // Range Maximum
                        0x01,               // Alignment
                        0xFF,               // Length
                        _Y21)
                })

 in bytecode: 11 0D 0A 47 01 00 00 00 00 01 FF 79 00

3) No CPU power saving, most time CPU in C0 state even without cpu load
    Some part of acpi hardware is disabled, so CPU should not use nonexistent ACPI C2/C3 power savings, solved, two solutions (intelppm.sys):
    1) C2/C3 States => C1 State :
        - in _InitializeAcpi2IoSpaceCstates replace offsets AcpiC2Idle and AcpiC3ArbdisIdle to offset AcpiC1Idle

    2) C2/C3 States => C7+ States (default Windows 7 power saving mode, DPC Latency Checker shows significal increased latency in this mode):
Replace Acpi2C3ArbdisIdle to:

push    ebx
mov     ebx, ecx
push    esi
push    0
call    _KeQueryPerformanceCounter
mov     [ebx], eax
mov     [ebx+4], edx

mov     eax, offset DummyMon
xor     ecx, ecx
xor     edx, edx
monitor
mov     ecx, 1
mov     eax, 60h
mwait

push    0
call    _KeQueryPerformanceCounter
mov     [ebx+8], eax
mov     [ebx+0Ch], edx
xor     eax, eax
pop     esi
pop     ebx
retn

DummyMon - any unused 4 byes in .data segment
Replace Acpi2C2Idle:

push    ecx
push    0               
call    _KeQueryPerformanceCounter
mov     ecx, [esp+4+var_4]
mov     [ecx], eax
mov     [ecx+4], edx

mov     eax, offset DummyMon
xor     ecx, ecx
xor     edx, edx
monitor
mov     ecx, 1
mov     eax, 33h
mwait

push    0               
call    _KeQueryPerformanceCounter
pop     ecx
mov     [ecx+8], eax
mov     [ecx+0Ch], edx
xor     eax, eax
retn

4) Programs show wrong timing results/works only first 3.5 sec
 Windows XP SP2+ uses disabled acpi timer, solved
 Skylake+ bioses by default disable ACPI hardware timer (register "ACPI Timer Control (ACPI_TMR_CTL)"  in southbridge, see PDF), but WinXP SP2+ still uses disabled acpi timer for getting incremental  time counter (acpi spec declare this counter as part of specification). WinXP detect existing this timer  by checking special bit USE_PLATFORM_CLOCK in FACP ACPI table, modern bioses still set USE_PLATFORM_CLOCK=1  in acpi (mistake by programmers / inform Win7+ about existing HPET timer (not acpi timer!))

 Patch (by Diderius) "HAL_acpitimer_fix" to use CPU TSC counter as performance timer/counter:
   - in HaliAcpiTimerInit force to ignore USE_PLATFORM_CLOCK and receive it always =0
     (v.5512 jns short PAGE:8002934B => jmp short PAGE:8002934B)

Compatibility fix ("HAL TSC frequency divider")
   Some programms do wrong calculation with high values of PerformanceCounter/PerformanceFrequency
   (HAL_acpitimer_fix set values to cpu freq), to avoid this problem values need to divide to much
   lesser value, Windows 7 just divide it to 1024, so timer frequency on 3600Mhz cpu is only 3.51Mhz
 Patch:
   - divide to 1024 values of PerformanceCounter/PerformanceFrequency, replace _HalpAcpiTimerQueryPerfCount to:

Quote

 mov     al, _HalpUse8254
 or      al, al
 nop
 nop

 mov     ecx, [esp+4]
 or      ecx, ecx
 jz      short Skip_Frequency_Mode
 mov     eax, fs:0A4h ; FrequencyLo
 mov     edx, fs:0A8h ; FrequencyHi
 shrd    eax, edx, 0Ah
 shr     edx, 0Ah
 mov     [ecx], eax
 mov     [ecx+4], edx
Skip_Frequency_Mode:
 rdtsc
 add     eax, fs:0ACh ; CalibrationLo
 adc     edx, fs:0B0h ; CalibrationHi
 shrd    eax, edx, 0Ah
 shr     edx, 0Ah
 retn    4

5) No driver for Intel SATA Controller - BSOD 0x7B(..,..,..,..)
 Windows XP/2003 support SATA controllers only in Legacy IDE mode, modern Intel chipsets has only AHCI mode, solved, many solutions:
 1) Intel RST  AHCI/RAID 11.2.0.1006 (iaStor.sys)
 2) Intel RSTe AHCI/RAID  4.7.0.1098 backport by daniel_k (iaStorA.sys+iaStorF.sys)
 3) StorAHCI by skulltera/OneCore (storahci.sys), compiled from Microsoft Windows 8.x DDK Samples, (require storport.sys from Windows 2003)
 4) UniATA (opensource)
 5) Intel RSTe AHCI/RAID  4.0.2.1019, for Windows 2003 only, enterprise controllers only(??) (iaStorA.sys+iaStorF.sys))
 6) StorAHCI from Windows 8 (require backported storport.sys from Windows 8)
 7) StorAhci for Windows 2003, based on Microsoft Windows 8.x DDK Samples source code, https://sourceforge.net/projects/storahci-for-windows-2003/

 Tip: Add PCI\VEN_8086&CC_0106 or PCI\VEN_8086&CC_010601 to *.inf as universal DEV_ID for any Intel AHCI Sata Controller
 

AMD Motherboards Issues
ACPI BSOD 0xA5 (0x0000000D, ..., ..., ...) duplicated _HID method
    Patch:
        - Skip DetectDuplicateHID processing
    (v5512 .text:00013F6C => jmp .text:00013F6C)

BSOD 0x7E (..., ..., C0000005, ...) unknow error in AcpiArbCrackPRT
    Patch:
    (v5512 jnz short .text:0001BD6D => jmp short .text:0001BD6D)
 

Intel USB3 Controller Drivers
 Intel released USB3.x drivers only for Windows 7/8/10, so there were many attempts to use drivers of
 other usb chip manufacturers. Most of them do not work at Intel hardware, some works, but have problems with PAE or USB3 ports.
 
 Following drivers confirmed to work in normal and PAE environment, solved, three solutions:
   1) Microsoft Generic v6.2.9200.16384/v6.2.9200.22453 from Windows 8.0, recommended driver
   2) AMD v1.1.0.0145 (need amdxhci_adresscalc_fix)
   3) Fresco Logic v3.6.9.0 (extended to 32 ports)

AMD and Fresco drivers have ssues with recognizing devices after plug<->unplug, sometimes ports go to power saving modes and can't back

UAS (Attached SCSI Mass Storage) drivers also available, solved, many solutions:
   1) UAS Driver from Windows 8 + storport.sys from Windows 2003, beta
   2) UAS Driver from Windows 8 + storport.sys from Windows 7, beta
   3) UAS Driver from Windows 8 + storport.sys from Windows 8, beta
   4) VIA UAS Driver
   5) Etron UAS Driver

VIA and Etron UAS Drivers doesn't support Safe Remove, require fixes, solved (via_uas_fix, etron_uas_fix)
By default  VIA and Etron UAS works only with genuine vendor USB3.0 Driver, but they are generic(?) and can work with any USB3 driver
vusbstor.inf:  change USB_VIA\Class_08&SubClass_06&Prot_62 to USB\Class_08&SubClass_06&Prot_62
EtronXHCI.inf:  change ENUSB\Class_08&SubClass_06&Prot_62 to USB\Class_08&SubClass_06&Prot_62

Patches for Microsoft Generic USB3 driver
Windows 8 USB3 driver always report USB2 speed on inserted USB3 devices, MS call it "compatibility", but vendors driver report proper USB3 speed and dont have compatibility issues(?)

Fix to report proper USB3 speed, usbhub3.sys (v6.2.9200.21180):
.text:19C58: jnz 00019C63 => jmp  00019C63 (75 09 => EB 09)

Patch for AMD driver (amdxhci_adresscalc_fix)
   This driver is known to have issues with PAE environment, need fix:
    - replace in amdxhc.sys:

    mov     ecx, [esi+458h] ; esi+458h = store of 64bit adress
    mov     eax, [esi+28h]
    mov     [eax], ecx            ; low part
    mov     [eax+4], ebx          ; dropped high part, ebx=zeroes.....

    to

    mov     ecx, [esi+458h]
    mov     eax, [esi+28h]
    mov     [eax], ecx
    mov     ecx, [esi+45Ch] ; HIGH part of 64bit
    mov     [eax+4], ecx    ; no more zeroes

Patch for VIA UASP driver (via_uas_fix)
Restore "Safe Remove":
- replace in vusbstor.sys (v6.1.7600.4002):
page:000209B4: mov     [ebp+SurpriseRemovalOK], ebx -> NOPs
(89 9D 70 FF FF FF 89 9D 68 FF FF FF => 90 90 90 90 90 90 89 9D 68 FF FF FF)

Patch for Etron UASP driver (etron_uas_fix)
Restore "Safe Remove":
- replace in EtronSTOR.SYS (any version):
OR dword ptr [eax+4], 0300h -> OR  dword ptr [eax+4], 0000h
 

4GB+ RAM Support
- Windows 2003 supports more than 4Gb RAM without additional actions, limited to some value depending "Edition"
- Windows XP ServicePack1 supports more than 4Gb RAM without additional actions, limited to some value (16Gb ?)
- Windows XP ServicePack2/3 don't support RAM above 4Gb, need patching, solved, many solutions:
      1) PatchPae(v2) by wj32, remove limits only in kernel, lack of HAL_DMA patch
      2) fix128/PatchPae(v3) by Evgen_b, contains unfinished HAL_DMA patch, kernel patch is OK
      3) WinXPPAE(v2+) by Daniel_k, contains proper HAL_DMA patch, kernel patch is OK

UEFI Boot
 - Bootmgr from some Vista Betas/Longhorns allow boot Windows XP x64 from UEFI x64, alpha,
   there is issues with Video card,  https://www.betaarchive.com/forum/viewtopic.php?f=61&t=20327
- Boot Windows x32 on UEFI 32
  UEFI32 on real hardware is rare, confirmed only on emulated environment, alpha, Guide LINK by Gelip
 - Quibble bootloader (experimental, opensource), alpha, no NTFS support,
   booting possible only if Windows installed on FAT partition, project page - https://github.com/maharmstone/quibble
 
NVMExpress Drivers
Many solutions:
  - Modified OFA 1.3/1.5 driver + storport.sys from Windows 2003
  - MS Windows 7 NVMe Driver by daniel_k + backported storport.sys from Windows 7
  - MS Windows 7 NVMe Driver + storport.sys from Windows 7 + Emu_Extender
  - Samsung NVMe driver + storport.sys
 

GPT partitions
Windows 2003 already supports GPT Partitions for non-booting disks, no need additional software
Windows XP doesn't support GPT Partitions, solved for non-booting disks, one solutions:
   -  Paragon GPT Loader enable access to 3TB+ Disks/GPT partitions (commercial product, currently not available for sale)

Booting from GPT disk partially solved, need convert pure GPT to HybridMBR, Guide LINK by Levvon
 

Saving crash dumps through storport based disk controller drivers
To enable saving crash dumps with storport-based disk drivers on Windows XP need patch kernel (scsi support will be disabled)
Disk Controller drivers written for Windows 8 mostly will not save crash dumps on disk, they use new API to get information from kernel about dump context
List of patches:
1) IopGetDumpStack:
Replace unicode string "scsiport.sys" to "storport.sys"
This string is 3rd argument of "call _IopLoadDumpDriver@12"
2) IopGetDumpStack:
Original XP kernel will disable loading storport emulator(diskdump.sys) if storport/miniport return "Device Object"
This is not problem for Windows 2003/7/.., newer OS still load diskdump.sys even if storport/miniport return anything

Replace "mov [ebp+ScsiDump], 0" with NOPs
Example for ntkrpamp.exe v5512:
PAGE:004A0E0F mov byte ptr [ebp-29h],0 -> NOP, NOP, NOP, NOP
]3) IopGetDumpStack:
Storport doesnt use SCSI ports names and dont need to search name of driver, need to skip this block
Example for ntkrpamp.exe v5512:
in range PAGE:004A0F49-004A1018 replace first opcode with "jmp 4A1019"
4) Use diskdump.sys from Windows 2003 or Wondows 7 (Windows 8 version not tested)
5) IoInitializeCrashDump:
XP kernel allocate for diskdump.sys buffer of 32Kb (same size in Windows 2000), diskdump.sys from Windows 2003+
expect buffer of 64Kb. To be compatible with new diskdump.sys need to increase buffer
Replace "push 8000h" with "push 10000h" as 3rd arg of ExAllocatePoolWithTag call

Modded AVX/AVX2 kernel
Currently Proof-Of-Concept, only one kernel version supported LINK


Projects for Developers/Advanced Users
 - Remote kernel debug over LAN or USB3 cable, https://github.com/MovAX0xDEAD/KDNET
 - ACPI DSDT/SSDT Patcher at boot time for any windows, https://github.com/MovAX0xDEAD/ACPI-Patcher
 - WinXP/W2003 ntoskrnl.exe Emu_Extender, https://github.com/MovAX0xDEAD/NTOSKRNL_Emu, https://msfn.org/board/topic/181615-ntoskrnl-emu_extender-for-windows-xp2003/

Research & Experiments
Running Windows XP with "new generation" ACPI.sys taken from many Vista Beta/Longhorn version
Running existing USB3 vendor's drivers on Intel USB3.0 controller
Implementation of ACPI Timer/HPET on different windows generations
Switching between DMA32/DMA64 under PAE Environment, Windows XP
Switching between DMA32/DMA64 under PAE Environment, Windows 7


Unresolved Problems/Requested Features:
- ACPI.SYS v.6666 lack 64-bit integers
- ACPI.SYS v.6666 limits possible datatypes in arguments only to ACPI 1.0b Specification
- Boot Windows XP/2003 x32 from UEFI x64
- Generating TRIM command for SSD in filesystem (NTFS/???)
- Internal GPT support for x32 Windows XP by replacing disk.sys/partmgr.sys/??? from Windows 2003
- Boot Windows x32 XP/2003 from pure GPT
- Restore full Windows XP SP1 implementation of PAE/DMA for Windows XP SP3
- Generic/Universal HDA Audio driver
- CSM Emulator for UEFI x64
- DirectX 10/11 kernel support
- NDIS 6.x for Windows XP/2003
 

Edited by Mov AX, 0xDEAD
Link to comment
Share on other sites


@Mov AX, 0xDEAD

I am very much interested in NDIS 6.x for Windows XP/2003.

Especially for a driver for the Intel Lan i219 under XP.

Because a lot of boards now on the market without Realtek RTL8111H or Intel <i219 network,

but also still a lot of new boards with the i219 chip

Dietmar

Link to comment
Share on other sites

VMWare is wrote min-port and used Mesa Winsys for Video , we can write a minport with UEFI support , and use Opengl/Vulkan/OpenCL/Directx9 on modern Intel/AMD GPU even on Nvidia with terrible performance.

https://archive.mesa3d.org/

mesa-21.2.6/src/gallium/frontends/wgl/stw_device.c

You can check it out , XP DDK and Server 2003 DDK have some driver example for Display.

Thing is studying the driver and mesa and making a new driver , not gonna be easy but 80% work is already done by Mesa guys.

Speaking of Intel i219

https://doxygen.reactos.org/dir_1fd5db4229a5858743134ea1546c500f.html

Linux kernel have e1000e interrupts linked in the driver.

https://github.com/ddk50/winkvm 

This WinKVM have Linux Kernel Mode Api wrapper,

Linux ALSA driver can be ported for Universal audio driver to Windows XP , including WiFi 6 driver.

Edited by Dibya
Link to comment
Share on other sites

  • 2 weeks later...
On 4/17/2022 at 12:31 PM, George King said:

@Mov AX, 0xDEAD 

In was wondering about x64 UEFI based PC to boot 32 bit XP - Do you think is possible to compile current NTLDR as NTLDR.efi x86_x64 target?

1) ntldr x32 based on BIOS API, Itanium version has some EFI support, i did not discovered it

2) bootvid.dll requires CSM Video to show something on screen

3) better try longhorn/vista bootmgr with native efi support to load legacy xp kernel

Link to comment
Share on other sites

  • 2 weeks later...
Quote

Compatibility fix ("HAL TSC frequency divider")
 

@Mov AX, 0xDEADIs there a safe space to add assembly code in existing dll file?  I tried patching two new subroutines to an empty 0000000 block at the end of the file, but it does not like it.  Windows restarts a few seconds after loading with this patch.

x86rtc-HAL-TSC-frequency-divider.png

 

Link to comment
Share on other sites

10 hours ago, pappyN4 said:

@Mov AX, 0xDEADIs there a safe space to add assembly code in existing dll file?  I tried patching two new subroutines to an empty 0000000 block at the end of the file, but it does not like it.  Windows restarts a few seconds after loading with this patch.

@pappyN4

You cannot reference to "end of file", dll is PE format. PE format is collection of segments mapped to near regions of memory

hal.dll has many segment, you can use only segment marked as .TEXT or one of .PAGE*, don't use .INIT

look at end of each segment to see how much bytes are free before address of next segment

1) for example halmaci.dll sp3 v5512 has free ~120 bytes in .text from .text:8001900D to .data:80019080

2) in any PE Editor increase .text segment virtual(mapped to memory) size from 0x8C0D to raw(size in file) size  0x8C80

Link to comment
Share on other sites

  • 1 month later...
On 4/6/2022 at 1:22 PM, Mov AX, 0xDEAD said:

Modded AVX/AVX2 kernel
Currently Proof-Of-Concept, only one kernel version supported LINK

Link not working. Also did it work now with XP-64 recently? I remember you, for some reason, didn't want to do version for XP64. But can you, please, do it?

On 4/6/2022 at 1:22 PM, Mov AX, 0xDEAD said:

3) WinXPPAE(v2+) by Daniel_k, contains proper HAL_DMA patch, kernel patch is OK

And where is link on this? I couldn't find it in google.

Link to comment
Share on other sites

On 6/21/2022 at 3:06 AM, Rod Steel said:

Link not working. Also did it work now with XP-64 recently? I remember you, for some reason, didn't want to do version for XP64

There is no free space in thread context to store all x64 AVX registers, no easy way to make it same as x32 version.

Link to comment
Share on other sites

8 hours ago, Mov AX, 0xDEAD said:

There is no free space in thread context to store all x64 AVX registers, no easy way to make it same as x32 version.

Perhaps i am not educated about this topic at all. I just ask about first AVX, not AVX2, not AVX512

You early write on win-raid:

Quote

P.S. WinXP x64 kernel has different FPU context format, but i think it is possible to do same trick, but i'm not interested

P.S.S Don't ask for AVX512, there is no free space in FPU context to store additional 16*AVX512_H(256bit) regs.

SO i ask does it possible to do AVX1 for XP64, or you are steel "not interested".:unsure:

Link to comment
Share on other sites

On 6/22/2022 at 11:36 PM, Rod Steel said:

Perhaps i am not educated about this topic at all. I just ask about first AVX, not AVX2, not AVX512

You early write on win-raid:

SO i ask does it possible to do AVX1 for XP64, or you are steel "not interested".:unsure:

avx1/2 on x32 are 8 256-bit registers YMM0-YMM7

avx1/2 on x64 are 16 256-bit registers YMM0-YMM15

x64 user applications can use all 16 registers, this is problem, 16*256/8= 512 bytes to store all x64 avx1/2 registers

Link to comment
Share on other sites

2 hours ago, Mov AX, 0xDEAD said:

avx1/2 on x32 are 8 256-bit registers YMM0-YMM7

avx1/2 on x64 are 16 256-bit registers YMM0-YMM15

x64 user applications can use all 16 registers, this is problem, 16*256/8= 512 bytes to store all x64 avx1/2 registers

Anyway to add FPU space?

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...