XP running on a 486 cpu

[Dietmar]

@roytam1

I can try, just send it to me

Dietmar

PS: Cpu load always 100%. It is stable but slowww..

[roytam1]

29 minutes ago, Dietmar said:

@roytam1

I can try, just send it to me

Dietmar

PS: Cpu load always 100%. It is stable but slowww..

you can grab it here: https://download.qt.io/development_releases/prebuilt/d3dcompiler/msvc2010/D3DCompiler_43-x86.dll.7z

[roytam1]

and BTW last VC10 firefox build (i.e .35.0.1) runs on 486.

[Dietmar]

@roytam1

I check careful: No cmpxchg8b is in this file D3DCompiler_43.dll

Dietmar

[roytam1]

29 minutes ago, Dietmar said:

@roytam1

I check careful: No cmpxchg8b is in this file D3DCompiler_43.dll

Dietmar

hmm, then it is objdump's false positive.

[Dietmar]

Hi,

does somebody know, where the question about cmpxchg8b "is there" in the XP.iso happens during Setup?

And also the same for CPUID. May be, we can take a look at the XP SP1 source files for this question.

I do a check, why my XP SP3 was so slow on the Shuttle Hot 433 board with AM486DX4-S cpu with 100 MHZ.

Oh, XP SP3 gets only 32 MB from the 256 MB installed memory, I think, because of only 256k Cache.

And half of memory because of "write-back" whatever this means for Cache^^..

(should be full memory with Cache settings to write-through)

So lets have some more fun with an install xp.iso for 486 cpu, 256 MB ram at 180 MHZ

Dietmar

Edited April 16 by Dietmar

[roytam1]

10 hours ago, Dietmar said:

Hi,

does somebody know, where the question about cmpxchg8b "is there" in the XP.iso happens during Setup?

And also the same for CPUID. May be, we can take a look at the XP SP1 source files for this question.

I do a check, why my XP SP3 was so slow on the Shuttle Hot 433 board with AM486DX4-S cpu with 100 MHZ.

Oh, XP SP3 gets only 32 MB from the 256 MB installed memory, I think, because of only 256k Cache.

And half of memory because of "write-through" whatever this means^^..

So lets have some more fun with an install xp.iso for 486 cpu, 256 MB ram at 180 MHZ

Dietmar

IIRC SETUPLDR checks CPUID for CX8 as well, maybe winnt.exe and winnt32.exe and usetup(i.e. smss.exe on disc) all have same check to prevent 486 Win2000 users to upgrade.

Edited April 15 by roytam1

[user57]

since its finalized you should write a protocol and make a release

you told us it´s acting oddly slow ? maybe you should try the code i posted up 
it actually can be that the reaction sometimes, 1 effect can be that the subtraction dont cause it to pop/push that well
then might a escape or other logic has to take it out

happy to see that you found a new section to use too, i told you its risky just to use other ram and the one you had where used

roytram gave you the right solution for this

happy to see the 486 working well 

interesting to see XP actually choose 32 MB instead of 256 MB 

caches useally makes the the computer faster 
https://learn.microsoft.com/en-us/windows/win32/api/winioctl/ns-winioctl-storage_write_cache_property
https://www.seagate.com/de/de/support/kb/disabling-the-write-cache-feature-in-windows-2000-xp-vista-and-windows-7-187751en/
 

[roytam1]

did a google search and found an interesting article: https://www.geoffchappell.com/studies/windows/km/cpu/cx8.htm

Edited April 17 by roytam1

[user57]

happy to see chappel again 

the first function mentioned actually tells a discrete use for that cmpxchg8b command
in 32 bit mode making a 64 bit change (ExInterlockedCompareExchange64)

the sequence chappel mentions is actually the same as the code i wrote

chappel also says microsoft use that code if, if the cmpxchg8b command was not found

chappel they says microsoft stopped to use to make that check since windows 5.1 (xp) (so we are a little smarter in that sence now)

howeever the next part tells a downside, chappel says that needs a storage object for multiprocessors (that  SLIST_HEADER structure actually might be a storage object)

but actually i use 2 move for exactly what chappels mentions (64 bit PTE´s, i build up those entrys then move it 2 times (high and low parts) ), and it dont cause a crash for what i did use that

that might need a confirm from others, maybe it is worth a try (and dietmar has a 486 cpu that one dont use more processors/hypterthreading - anyways)

a thread/processor switch takes time

if that would be random the entire kernel would interfere anytime - the biggest BSOD i can think of

dietmar might can need the next part from chappel that mentions what microsoft is doing to test if that command is available

he says microsoft checks (before winxp) that by masking the eflags with the mask 0x00200000

if that cant be done there is no CPUID command
(that information is already "almost" enough
to not use the cmpxchg8b command)
but microsoft makes it correct
if the first mask check can be done, microsoft use the cpuid command and checks for the CX8 flag - this makes certain if the cpuid command is available and also checks for the cmpxchg8b command to be available just in case the cpu dont support chmpxchg8b but actually have the cpuid command)

i think dietmar can need that information if he makes his 486 (dll) he mentioned , and want to make the check correct

[jumper]

Use in drivers is a problem. GPU's and NIC's are just two peripherals with controllers that can access the data bus at the same time as the CPU.

 

[Dietmar]

Here are 2 photos of my Shuttle Hot 433 board, with running full XP SP3 on it.
I notice, that even from version 1...3 of this board, they have different IDE controllers, so you cant switch from one board to next with the same XP SP3 installation. This strange behavior I have never seen for any IDE controller before.

Next step is to build an full Setup XP486.iso.

I make a try, to overcome also there the crazy opcode cmpxchg8b and also the "Unknown Processor" hurdle.

Any help is welcome, which files on the xp.iso have to be changed, for to kick out those checks.

It is not so much difficult I think.

My files without any cmpxchg8b are quite stable, anyway I will update them and I also make an english version

Dietmar

 

Edited April 21 by Dietmar

[roytam1]

On 4/22/2024 at 12:42 AM, Dietmar said:

My files without any cmpxchg8b are quite stable

only on 486. if you try this on newer machines you may see more BSoDs.

[Dietmar]

@roytam1

On my Asrock z370 k6 board with 8700k cpu all my files without any cmpxchg8b are stable.

But this is not the case for the 486 cpu.

Strange.

I think, it depends only on the simulation of cmpxchg8b in ntoskrnl.exe in the function ExInterlockedPopEntrySList.

But I dont have a better idea until now for this simulation of cmpxchg8b there

Dietmar

[Dietmar]

Yessaaaa,

now the simulation of cmpxchg8b is much better, here in ntoskrnl.exe

Dietmar

New ntoskrnl.exe for 486 compi

https://ufile.io/3e0u7qi7

.data:004762F2 ; Exported entry   8. ExInterlockedPopEntrySList
.data:004762F2 ; Exported entry  36. InterlockedPopEntrySList
.data:004762F2
.data:004762F2 ; =============== S U B R O U T I N E =======================================
.data:004762F2
.data:004762F2
.data:004762F2                 public ExInterlockedPopEntrySList
.data:004762F2 ExInterlockedPopEntrySList proc near    ; CODE XREF: sub_40E06D+1DAp
.data:004762F2                                         ; sub_41159B+8Ap ...
.data:004762F2                 push    ebx             ; ExInterlockedPopEntrySList
.data:004762F3                 push    ebp
.data:004762F4                 mov     ebp, ecx
.data:004762F6
.data:004762F6 loc_4762F6:                             ; DATA XREF: .text:loc_40A835o
.data:004762F6                                         ; KiDeliverApc+12o
.data:004762F6                 mov     edx, [ebp+4]
.data:004762F9                 mov     eax, [ebp+0]
.data:004762FC
.data:004762FC loc_4762FC:                             ; CODE XREF: ExInterlockedPopEntrySList+18j
.data:004762FC                                         ; ExInterlockedPopEntrySList+23j
.data:004762FC                 or      eax, eax
.data:004762FE                 jz      short loc_476317
.data:00476300                 lea     ecx, [edx-1]
.data:00476303
.data:00476303 loc_476303:                             ; DATA XREF: sub_40A552:loc_40A55Bo
.data:00476303                                         ; .text:loc_40A747o
.data:00476303                 mov     ebx, [eax]
.data:00476305
.data:00476305 loc_476305:                             ; DATA XREF: KiDeliverApc+1Bo
.data:00476305                 lock cmpxchg [ebp+0], ebx
.data:0047630A                 jnz     short loc_4762FC
.data:0047630C                 push    eax
.data:0047630D                 mov     eax, edx
.data:0047630F                 lock cmpxchg [ebp+4], ecx
.data:00476314                 pop     eax
.data:00476315                 jnz     short loc_4762FC
.data:00476317
.data:00476317 loc_476317:                             ; CODE XREF: ExInterlockedPopEntrySList+Cj
.data:00476317                 pop     ebp
.data:00476318                 pop     ebx
.data:00476319                 nop
.data:0047631A                 nop
.data:0047631B                 nop
.data:0047631C                 nop
.data:0047631D                 nop
.data:0047631E                 nop
.data:0047631F                 retn
.data:0047631F ExInterlockedPopEntrySList endp
.data:0047631F
.data:0047631F ; ---------------------------------------------------------------------------

 

Edited April 23 by Dietmar