News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

LOADALL

Started by bomz, December 26, 2011, 04:02:19 AM

Previous topic - Next topic

bomz


http://www.rcollins.org/articles/loadall/tspec_a3_doc.html
http://function.name/in/Assembler/LOADALL
http://ftp.gwdg.de/pub/misc2/x86.org/source/386load/386load.asm
http://ftp.gwdg.de/pub/misc2/x86.org/source/386load/loadfns.386
http://ftp.gwdg.de/pub/misc2/x86.org/source/386load/macros.386
http://ftp.gwdg.de/pub/misc2/x86.org/source/include/cpu_type.asm
http://www.dcee.net/Files/Programm/Asm/
http://www.dcee.net/Files/Programm/Asm/loadall.arj
;---------------------------------------------------------------
;---------------------------------------------------------------
.386P
CSEG segment
assume cs:cseg, ds:cseg, ss:cseg, es:cseg
org 100h
start:
;---------------------------------------------------------------
;---------------------------------------------------------------
; Structure definitions
;---------------------------------------------------------------
Loadall_struc   STRUC
_Cr0 dd 0
_Eflags dd 0
_Eip dd 0
_Edi dd 0
_Esi dd 0
_Ebp dd 0
_Esp dd 0
_Ebx dd 0
_Edx dd 0
_Ecx dd 0
_Eax dd 0
_Dr6 dd 0
_Dr7 dd 0
_Tr dd 0
_Ldt dd 0
_Gs dd 0
_Fs dd 0
_Ds dd 0
_Ss dd 0
_Cs dd 0
_Es dd 0
TSS_Desc dd 00008900h,00000000h,00000800h
IDT_Desc dd 00000000h,00000000h,000003ffh
Gdt_Desc dd 00000000h,00000000h,00000000h
Ldt_Desc dd 00008200h,00000000h,00000088h
GS_Desc dd 00009300h,00000000h,0000ffffh
FS_Desc dd 00009300h,00000000h,0000ffffh
DS_Desc dd 00009300h,00000000h,0000ffffh
SS_Desc dd 00009300h,00000000h,0000ffffh
CS_Desc dd 00009b00h,00000000h,0000ffffh
ES_Desc dd 00009300h,00000000h,0000ffffh
Loadall_Struc   ENDS

pushfd
pop eax
mov Loadall_tbl._Eflags,eax
xor eax, eax
mov eax, cs
mov Loadall_tbl._CS,eax
mov Loadall_tbl._DS,eax
mov Loadall_tbl._ES,eax
mov Loadall_tbl._SS,eax

mov eax,cs
shl eax,4
mov Loadall_tbl.CS_Desc+4,eax
mov Loadall_tbl.DS_Desc+4,eax
mov Loadall_tbl.ES_Desc+4,eax
mov Loadall_tbl.SS_Desc+4,eax

mov eax,cr0
mov Loadall_tbl._CR0,eax
mov eax,dr6
mov Loadall_tbl._DR6,eax
mov eax,dr7
mov Loadall_tbl._DR7,eax
mov Loadall_tbl._EIP,offset Verify_State
mov edi,offset loadall_tbl
cli
        mov     Loadall_tbl._ESP,esp
db 0Fh, 7 ;LOADALL
nop

Verify_State:
sti
ret

;---------------------------------------------------------------
; Loadall table(s)
;---------------------------------------------------------------
        Loadall_tbl     Loadall_struc <>

;---------------------------------------------------------------
CSEG ends
end start
;---------------------------------------------------------------
;---------------------------------------------------------------

sinsi

0F 07 (386 LOADALL) is SYSRET on a 64-bit CPU and generates an exception if not in 64-bit mode, according to the Intel docs.
0F 05 (286 LOADALL) is SYSCALL, problems like above.
Light travels faster than sound, that's why some people seem bright until you hear them.

MichaelW

I think the LOADALL functionality is long gone because after the 286 there was no actual need for it.
eschew obfuscation

sinsi

>I think the LOADALL functionality is long gone because after the 286 there was no actual need for it.
Since it was mainly used for a quick rm<->pm switch on a 286 I wuold imagine nobody uses it now.
One of those links says that 486 BIOSes actually had to code for #UD to emulate it, since its use was so widespread.

I'm sure that there are a lot of undocumented opcodes that Intel used to test things, they are usually tied to one particular CPU stepping.
A bit like MS with their internal workings of Windows. People find them, publish what they think it does then it disappears...and wrecks programs.
Raymond Chen is always talking about the hoops MS go through for backwards compatibility - people blame MS, not the program.

Light travels faster than sound, that's why some people seem bright until you hear them.

bomz

for 386 it considering like DOCUMENTED, hymem.sys use it (I forgot URL where I find hymem.sys sources).

MichaelW

#5
I don't recall HIMEM.SYS using LOADALL. Per Geoff Chappell, in his book DOS Internals (1994), HIMEM.SYS accesses extended memory from real mode by increasing the descriptor cache segment limit. And in his discussion of LOADALL, which I just reread, I see no references to HIMEM.SYS. However, he does state that as late as 1987 RAMDRIVE.SYS relied on the 286 LOADALL for its extended memory access.

I think the only way to know if a 286 or 386 LOADALL will still function on a recent system running DOS is to test it. I doubt that running the DOS test app under any version of Windows from 95 through XP would provide useful information, because I think Windows is likely to emulate the LOADALL instruction.

eschew obfuscation

bomz

LOADALL not work in protected mode. But now it don't work in REAL mode. may be error in structure

FORTRANS

Hi,

   "The Undocumented PC", by van Gilluwe, says that LOADALL
was only used by the 286, 386, and some non-Intel 486's.  If
your processor is newer than those, it won't work unless it is
emulated by the BIOS.  And if running a protected mode OS
(other than your own) it will not be allowed in any fashion.

Regards,

Steve N.

bomz


It's early to real machine tests.

MichaelW

#9
The attachment contains a 16-bit DOS app that hooks the invalid opcode interrupt and executes a dummy 386 LOADALL instruction ("dummy" because I didn't have time to create a workable table for the instruction). On my P3 (~11 year old) system running Windows 2000 and my P2 (~12-year old) system running MS-DOS 6.22 the interrupt handler gets called. On my IBM 486SLC2-66 (~19-year old) system running MS-DOS 6.22, as far as I can tell by watching the screen closely the handler does not get called, and the system reboots. So the test would seem to indicate that LOADALL is not supported by anything resembling a recent processor, or system.

BTW, I found what appears to be a HIMEM.SYS 2.06 source from 1988 (at a link on the Wikipedia LOADALL page), and it does use LOADALL, but it's machine-check code only checks for 8086, 80286, and 80386.

Edit: Updated the code in the attachment so it can successfully execute a 386 LOADALL on my IBM 486SLC2 system, and hopefully on any system that supports the 386 LOADALL.

The...

    mov ax, @data
    mov ds, ax

... was just a quick fix that I added when I discovered that the print statement below it displayed garbage.  A better way to fix the problem would have been to initialize loadall_ds with the current DS value before executing LOADALL.
eschew obfuscation

bomz

All virtual processors give Invalid Opcode

FORTRANS

Hi MichaelW,

   "The Undocumented PC",  says that LOADALL is supported
by the IBM 486SLC2.  So that may be loading a bunch of
registers!  (And no exception...)  The 386 (non-Intel 486)
LOADALL loads from a table at ES:EDI according to van Gilluwe.
The IBM chips can load either 61 or 73 entries (his description
is inconsistent with his table).

Regards,

Steve N.

bomz

MichaelW
I study your code and don't understand how it work. You set INT 06h Bios Interrupt which called each time Ilegal Opcode occurs. But what happen if LOADALL support's by processor ?

MichaelW

Quote from: bomz on January 10, 2012, 12:06:30 AM
I study your code and don't understand how it work. You set INT 06h Bios Interrupt which called each time Ilegal Opcode occurs. But what happen if LOADALL support's by processor ?

The system reboots. At that point I was mostly trying to determine if LOADALL is supported by anything other than very old processors. After I posted I added a LOADALL table to the code and started adding the other code necessary to make it work on a system that does support the 386 LOADALL, and then forgot to finish it. I have now (hopefully) finished it and updated the attachment in my post.

eschew obfuscation

bomz