Chuck probably would like Forreal Mode for ColorForth
humbubba
Operation of the INTeL 80386 is clearly much more flexible than
currently
used, as far as the basic states the machine can run in. "Real Mode"
and
"Protected Mode" are two possibilities out of several that are
concievably
useful. It can be seen from things that are possible in "Real Mode",
such
as "Unreal Mode", use of 386-era instructions and so on, that the
canonical modes are not monolithic entities, but are cases of various
combinations of discrete state switches. There is no 8086 in a 386.
Canonical Wake-up Real Mode, which I will refer to as CWR Mode, seems
to
be how these several state switches are set at machine reset, but are
semantically just settings of independant things, and clearly CWR Mode
can
be set up from individual settings available to the user. This is also
much more evident from a careful traversal of the detailed instruction
specs in the INTeL Programmer's Reference (386INTEL.TXT) for the 80386.
I'd say the two most global switches in the machine are the PE bit,
Protection Enabled, quite sensibly placed at bit 0 in control register
0,
and the D bit of the active code segment descriptor affiliated with CS,
the Default Bit. Two bits gives four possible states. All four are
capable
of being the default mode of a system. Two are used as such; CWR Mode
and
Protected Mode. Here's a breakdown and some neologizing...
PE=0 Dbit=0 (un)Real Mode
PE=0 Dbit=1 Forreal Mode
PE=1 Dbit=0 Veal Mode (BKA "286 task")
PE=1 Dbit=1 Protected Mode
The documented modes are the outside cases in a binary-count listing,
where PE=Dbit. There's a very good reason for that. IRET is sensitive
to
Dbit, whereas interrupts push a stack frame of operands sized in
accordance with PE. This is some of INTeL's* description of the action
of
INT, which represents all interrupts in this regard, when PE=0...
IF PE = 0
THEN GOTO REAL-ADDRESS-MODE;
REAL-ADDRESS-MODE:
Push (FLAGS);
IF <! 0; (* Clear interrupt flag *)
TF <! 0; (* Clear trap flag *)
Push(CS);
Push(IP);
(* No error codes are pushed *)
CS <! IDT[Interrupt number * 4].selector;
IP <! IDT[Interrupt number * 4].offset;
That is, IP is pushed if PE=0, not EIP. FLAGS is also a dual (a "word"
in
INTeLese, 16 bits). Thus if, for example, you are in Forreal Mode, you
get
a 6-byte stack push of FLAGS, CS and then IP on an interrupt, and the
corresponding IRET will later pop 12 bytes for basically the same 3
registers, and the system streaks off to the big bitbucket in the sky.
HOW ever, IRET is only PARTIALLY sensitive to Dbit. What I didn't say a
moment ago is that IRET is really sensitive to the current effective
code
size, of which the D bit is just one component. If we prefix the IRET
in a
Forreal Mode interrupt handler with 0x66, the other-operand-size
prefix,
it will pop duals in a use32 CS. The interrupt occuring with PE=0
pushed
duals. It works. The inside cases of Veal Mode and Forreal Mode simply
need thier IRETs un-default-sized. In Veal Mode you coerce IRET into
using
quads in a use16 code segment, and in Forreal Mode the same prefix in a
use32 code segment will coerce the IRET pops to duals. In Veal Mode,
where
PE=1 when an interrupt occurs, you also have the option of handling the
interrupt with a Dbit=1 segment for the pertinent interrupt handler, in
which case it can IRET back to Veal Mode with a naked IRET. I suppose
you
can also segregate Veal Mode segments with thier descriptor bases and
limits. In all the quirkiness of the 386, the broad orthogonality of
the
other-sizing prefixes is quite refreshing, and even works on stuff like
POPA.
This is from the blow-by-blow description of IRET...
IF OperandSize = 32 (* Instruction = IRETD *)
THEN EIP <! Pop();
ELSE (* Instruction = IRET *)
IP <! Pop();
Again, OperandSize is Dbit as effected by a possible prefix.
This is why INTeL only mentions Veal Mode as "286 tasks". Tasks don't
IRET. Most of what a 386 provides big facilities for, like tasks, can
also
be done piecemeal, as would be the case running a system in straight
Forreal Mode.
Canonical Wake-up Real Mode and Unreal Mode are two flavors of the same
basic setting of PE and Dbit. The difference is in segment limits. This
points up a basic concept here. 8086-style segments are a lightweight
layer that may or may not be active, but 386 segments are always
active.
PE=0 does not turn them off. PE=0 means you can't change them until you
turn PE back to 1. PE should be called "PCE, Protections Changes
Enabled".
This means the four basic modes have a state diagram about like so...
_______________
| WAKE-UP |
|canonical rmode|
| PE=0 use16 |
|_______________|
A |set PE to 1
| |
set PE to 0| |
___|________V__
| Veal |
| Mode |
| PE=1 use16 |
|_______________|
A |far xfer
| | to use32 CS
far xfer to | |
use16 CS| |
___|_______V___
| Protected |
| Mode |
| PE=1 use32 |
|_______________|
A |set PE to 1
| |
set PE to 0| |
___|________V__
| Forreal Mode |
| Mode |
| PE=0 use32 |
|_______________|
Interesting. Forreal Mode is the furthest from Wake-up, and you can
only
get to Forreal Mode from pmode. Forreal Mode is like a back room off of
pmode. You can interrupt between pmode and Veal Mode. Conversely,
events
in rmode or Forreal Mode (PE=0) have to be handled in the mode they
occur
in.
The above diagram does not account for different segment limits and
bases
than those in effect in WakeUp Rmode, so e.g. unreal mode is not shown.
This chart also does not account for V86 Mode, which basically requires
386 task-switch constructs. The above modes and transitions do NOT need
a
TSS, or paging. I suspect V86 could run off Veal Mode OR pmode.
Veal Mode is a protected mode. That means it's a quick switch to good
old
use32 Protected Mode. It may afford some better code density, and thus
speed. Forreal Mode is unprotected, which means interrupts are handled
somewhat faster, which benefits realtime services. Either can be
incorporated into a multi-mode system. Forreal Mode also doesn't seem
to
have any analogy at all in current use, other than the INTeL "flat
model",
which is a simplified pmode, but that similarity is rather superficial.
For the 386 to do what it does, and particularly to have pulled it off
in
the mid-eighties, things have to be fairly simple. You can figure that
whatever the 386 does, it's implemented as simply as possible. The
modes
of the machine are composites of simple switches, and various effects,
such as loaded descriptors, tend to persist until changed. This has
always
been the case with e.g. 8086 segment registers. In the 386, however,
8086-style "segments" are not alternates of 386 segments, they are a
superficiality on top of them. With that in mind, the states one goes
through simply getting from real mode to pmode start to make more
sense.
The following (osimplay) code demonstrates the superficiality of 8086
"schmegments" vis-a-vis 386 segments, even when PE=0...
<from flat pmode>
. global/flipPE # Welcome to Forreal Mode
# cell still 4
= 4 to A # 32-bit schmegmented addressing demo
= A to ES # proving we got PE = to 0.
= 9348539 to A
= A to @ $((0xb8a00))
ES
= A to @ $((0xb8a00))
That code causes two identical attribute-glyph pairs to appear on the
VGA
text screen 32 charcells displaced from each other. That is the 4 in
ES,
times 16 as per 8086, divided by two since each charcell is 2 bytes.
Plus
a flat 32-bit address to put it on the screen. Forreal Mode thus does
32-bit 8086 schmegmented address computation. What is this type of
addressing useful for? Precious little. In Forreal mode you've got 32
bits
to start with. The point is you have the big flat segments left over
from
pmode. The 8086 address-math does prove we're not in pmode any more,
however. Otherwise the ES prefix of 4 would have GPFed.
Rick Hohensee
Precision Mojo Engineer
*
I've converted my 386INTEL.TXT to 7-bit ASCII-art, not to mention
op-source-dest and other unINTeLifications, and "<!" is the
right-to-left
assignment operator in the instruction description code, helpfully
pronounced "becomes".
The appended hex/octal/listing appears to be handling INT 35 in Forreal
Mode, ala
otheroperandsize
dismiss
It also demos the 32-bit schmegmented addressing mentioned earlier, and
it
keeps it's IDT in the VGA text buffer. The hex/octal input editor in
osimplay needed to type it in is Left As An Excercize To The Reader.
00000000 00... ALLOT 0x7C00
00007c00 270 28 02 = 552 to A
00007c03 271 01 00 = 1 to C
00007c06 31 322 XOR D with D
00007c08 8e 302 = D to ES
00007c0a 273 00 7c = 0x7c00 to B
00007c0d cd 13 submit 0x13
00007c0f fa nosurprises
00007c10 270 00 b8 = 0xb800 to A
00007c13 8e 330 = A to DS
00007c15 270 93 0d = 3475 to A
00007c18 89 006 2c 01 = A to @ 300
00007c1c 31 300 XOR A with A
00007c1e 8e 330 = A to DS
00007c20 0f 01 16 37 7d setGDT IGDTRpointer
00007c25 270 00 b8 = 0xb800 to A
00007c28 8e 330 = A to DS
00007c2a 270 94 0d = 3476 to A
00007c2d 89 006 30 01 = A to @ 304
00007c31 66 otheroperandsize
00007c32 31 300 XOR A with A
00007c34 100 1+ A
00007c35 0f 22 300 = A to CR0
00007c38 e9 00 00 jump hvfnvkfv
00007c3b (O) hvfnvkfv
00007c3b 89 006 34 01 = A to @ 308
00007c3f 89 006 35 01 = A to @ 309
00007c43 0f 20 300 = CR0 to A
00007c46 89 006 36 01 = A to @ 310
00007c4a 89 006 37 01 = A to @ 311
00007c4e ea 53 7c 10 00
00007c53 (O) u32
00007c53 270 18 00 00 00 = 0x18 to A
00007c58 8e 330 = A to DS
00007c5a 270 57 65 67 13 = 325543255 to A
00007c5f 89 005 d4 00 00 00 = A to @ 212
00007c65 89 005 d8 80 0b 00 = A to @ 753880
00007c6b 89 005 78 81 0b 00 = A to @ 754040
00007c71 89 005 18 82 0b 00 = A to @ 754200
00007c77 270 18 00 00 00 = 0x18 to A
00007c7c 8e 330 = A to DS
00007c7e 8e 300 = A to ES
00007c80 8e 320 = A to SS
00007c82 31 300 XOR A with A
00007c84 8e 340 = A to FS
00007c86 8e 350 = A to GS
00007c88 270 d1 00 00 00 = 0xd1 to A
00007c8d 272 64 00 00 00 = 0x64 to D
00007c92 ee send byte
00007c93 90 nop
00007c94 90 nop
00007c95 90 nop
00007c96 90 nop
00007c97 90 nop
00007c98 90 nop
00007c99 90 nop
00007c9a 90 nop
00007c9b 90 nop
00007c9c 90 nop
00007c9d 270 df 00 00 00 = 0xdf to A
00007ca2 272 60 00 00 00 = 0x60 to D
00007ca7 ee send byte
00007ca8 272 92 00 00 00 = 0x92 to D
00007cad ec recieve byte
00007cae 0d 02 00 00 00 OR 2 to A
00007cb3 ee send byte
00007cb4 (O) a20loop
00007cb4 270 55 55 aa aa = 0xaaaa5555 to A
00007cb9 89 005 d8 ff 1f 00 = A to @ 2097112
00007cbf 8b 035 d8 ff 1f 00 = @ 2097112 to B
00007cc5 39 303 -test A to B
00007cc7 0f 85 e7 ff ff ff when not zero a20loop
00007ccd 274 f0 ef 00 00 = 61424 to SP
00007cd2 31 377 XOR DI with DI
00007cd4 (O) perFMIDTvector
00007cd4 60 pushcore
00007cd5 270 aa 7d 00 00 = twitch32unP to A
00007cda e8 ae 00 00 00 call install32unP
00007cdf 61 pullcore
00007ce0 107 1+ DI
00007ce1 81 377 ff 00 00 00 -test 255 with DI
00007ce7 75 eb when not zero short perFMIDTvector
00007ce9 0f 01 1d bb 7d 00 00 setIDT IDT32unPpointer
00007cf0 31 333 XOR B with B
00007cf2 103 1+ B
00007cf3 0f 20 300 = CR0 to A
00007cf6 31 330 XOR B to A
00007cf8 0f 22 300 = A to CR0
00007cfb 270 04 00 00 00 = 4 to A
00007d00 8e 300 = A to ES
00007d02 270 bb a5 8e 00 = 9348539 to A
00007d07 89 005 00 8a 0b 00 = A to @ 756224
00007d0d 26 ES
00007d0e 89 005 00 8a 0b 00 = A to @ 756224
00007d14 66 otheroperandsize
00007d15 9c pushflags
00007d16 66 otheroperandsize
00007d17 68 00 00 push 0
00007d1a 66 otheroperandsize
00007d1b e8 8c 00 call twitch32unP
00007d1e (O) theloop
00007d1e 8b 005 88 88 0b 00 = @ 755848 to A
00007d24 100 1+ A
00007d25 89 005 88 88 0b 00 = A to @ 755848
00007d2b cd 23 submit 35
00007d2d 90 nop
00007d2e 90 nop
00007d2f 90 nop
00007d30 90 nop
00007d31 e9 e8 ff ff ff jump theloop
00007d36 f4 halt
00007d37 (O) IGDTRpointer
00007d37 00 04 3d 7d 00 00
00007d3d (O) GDT
00007d3d 00 00 00 00 00 00 00 00 0 the required
NULL
00007d45 ff ff 00 00 00 89 cf 00 1 0x8 TSS
stackstack
00007d4d ff ff 00 00 00 9a cf 00 2 0x10 ring0
USE32
CS
00007d55 ff ff 00 00 00 92 cf 00 3 0x18 ring0
data
00007d5d ff ff 00 00 00 9a 00 00 4 0x20 USE16 CS
00007d65 ff ff 00 00 00 92 00 00 5 0x28 USE16
data
?S
00007d6d 00 00 00 00 00 00 00 00 6 0x30
00007d75 00 00 00 00 00 00 00 00 7 0x38
00007d7d 00 00 00 00 00 00 00 00 8 0x40
00007d85 00 00 00 00 00 00 00 00 9 0x48
00007d8d
00007d8d (O) install32unP
00007d8d c1 347 02 upshift 2 to DI
00007d90 81 307 00 80 0b 00 + IDT32unP to DI
00007d96 89 007 = A to @ DI
00007d98 c3 return
00007d99 (O) install16
00007d99 c1 347 02 upshift 2 to DI
00007d9c 81 307 00 84 0b 00 + IDT16 to DI
00007da2 e8 1a 00 00 00 call schmegment
00007da7 89 007 = A to @ DI
00007da9 c3 return
00007daa (O) twitch32unP
00007daa 120 push A
00007dab 8b 005 50 8a 0b 00 = @ 756304 to A
00007db1 100 1+ A
00007db2 89 005 50 8a 0b 00 = A to @ 756304
00007db8 130 pull A
00007db9 66 otheroperandsize
00007dba cf dismiss
00007dbb (O) IDT32unPpointer
00007dbb 00 04 00 80 0b 00
00007dc1 (O) schmegment
00007dc1 123 push B
00007dc2 89 303 = A to B
00007dc4 c1 353 10 downshift 16 to B
00007dc7 81 340 ff ff 00 00 AND 65535 to A
00007dcd c1 343 1c upshift 28 to B
00007dd0 09 330 OR B to A
00007dd2 133 pull B
00007dd3 c3 return
Rick Hohensee
Rod Pemberton
"humbubba" <hohens...@yahoo.com> wrote in message
news:1159283228.0...@d34g2000cwd.googlegroups.com...
> The four actual main modes of the 386
>
First question: Is there a reason you keep posting the exact same post over
and over again, over a number of years, to various NGs?
Never mind... I'll bite and translate...
> Operation of the INTeL 80386 is clearly much more flexible
> than currently used
Fine.
<snip>
> PE=0 Dbit=0 (un)Real Mode
> PE=0 Dbit=1 Forreal Mode
> PE=1 Dbit=0 Veal Mode (BKA "286 task")
> PE=1 Dbit=1 Protected Mode
These would be better clarified using standard nomenclature:
PE=0 Dbit=0 16-bit Real Mode (and "unreal" mode)
PE=0 Dbit=1 32-bit Real Mode (?)
PE=1 Dbit=0 16-bit Protected Mode
PE=1 Dbit=1 32-bit Protected Mode
(?) I'm not sure if "32-bit Real Mode" is the proper nomenclature, but it is
far more accurate than "Veal" and "Forreal" mode...
<snip>
> ... that IRET is really sensitive to the current effective
> code size, of which the D bit is just one component.
Good observation. But, I think most are aware of operand and address size
prefixes and understand they can be used in every mode (other than 64-bit?).
> Canonical Wake-up Real Mode [sic, Real Mode]
> and Unreal Mode [sic, "unreal" mode] are two flavors of the same
> basic setting of PE and Dbit. The difference is in segment limits.
True.
> This points up a basic concept here. 8086-style segments are
> a lightweight layer that may or may not be active, but 386
> segments are always active.
> PE=0 does not turn them off. PE=0 means you can't change
> them until you turn PE back to 1. PE should be called
> "PCE, Protections Changes Enabled".
And, that's an advantage and different from PE meaning "Protection Enabled,"
how exactly?
> This means the four basic modes have a state diagram about like so...
In addition to the non-standard terminology, your diagram doesn't show the
changes in the D bit. Also, it appears that there is an error in your
diagram (below). And, one needs a fixed-width font to view it properly...
> _______________
> | WAKE-UP |
> |canonical rmode|
> | PE=0 use16 |
> |_______________|
16-bit Real Mode, D bit = 0
> A |set PE to 1
> | |
> set PE to 0| |
> ___|________V__
> | Veal |
> | Mode |
> | PE=1 use16 |
> |_______________|
16-bit Protected Mode, D bit = 0
> A |far xfer
> | | to use32 CS
> far xfer to | |
> use16 CS| |
> ___|_______V___
> | Protected |
> | Mode |
> | PE=1 use32 |
> |_______________|
32-bit Protected Mode, D bit = 1
> A |set PE to 1
> | |
> set PE to 0| |
I believe that is an error in your diagram:
A |set PE to 0
| |
set PE to 1| |
> ___|________V__
> | Forreal Mode |
> | Mode |
> | PE=0 use32 |
> |_______________|
32-bit Real Mode, D bit = 1
> Interesting. Forreal Mode [sic, 32-bit Real Mode] is the
> furthest from Wake-up [sic, 16-bit Real Mode], and you
> can only get to Forreal Mode [sic, 32-bit Real Mode] from
> pmode [sic, 32-bit Protected Mode]. Forreal Mode
> [sic, 32-bit Real Mode] is like a back room off of pmode
> [sic, 32-bit Protected Mode].
If true, I find it interesting that one can't just switch from 16-bit Real
Mode to 32-bit Real Mode [i.e., Forreal] like the other mode. Are you sure
you aren't "combining" the effects of "unreal" mode (big segments for Real
Mode) and 32-bit Real Mode?
> You can interrupt between pmode [sic, 32-bit Protected
> Mode] and Veal Mode [sic, 16-bit Protected Mode].
...
> Conversely, events in rmode [sic, 16-bit Real Mode]
> or Forreal Mode [sic, 32-bit Real Mode] (PE=0)
> have to be handled in the mode they occur in.
Okay, so what you are saying is: 'PM can execute both 16-bit and 32-bit code
segments, unlike RM where only 16-bit or 32-bit code segments can be
executed exclusively.' I'm not completely sure about that or this, but I
think the Intel manuals state that...
> The above diagram does not account for different segment limits and
> bases than those in effect in WakeUp Rmode [sic, 16-bit Real Mode],
> so e.g. unreal mode is not shown.
> This chart also does not account for V86 Mode, which basically
> requires 386 task-switch constructs. The above modes and
> transitions do NOT need a TSS, or paging. I suspect V86 could
> run off Veal Mode [sic,16-bit Protected Mode] OR
> pmode [sic,32-bit Protected Mode].
>
<snip>
> The following (osimplay) code demonstrates the superficiality of 8086
> "schmegments" vis-a-vis 386 segments, even when PE=0...
Even as an American, I appreciate the allusion to "Red Dwarf," but I suspect
it will be lost on many... "Smeg" was used in the TV show as a expletive
substitute.
<snip>
Rod Pemberton
humbubba
Rod Pemberton wrote:
> "humbubba" <hohens...@yahoo.com> wrote in message
> news:1159283228.0...@d34g2000cwd.googlegroups.com...
> > The four actual main modes of the 386
> >
>
> First question: Is there a reason you keep posting the exact same post over
> and over again, over a number of years, to various NGs?
>
I'm very flattered you remember posts from , what, two years ago?
> Never mind... I'll bite and translate...
Wunderbar!
>
> > Operation of the INTeL 80386 is clearly much more flexible
> > than currently used
>
> Fine.
>
> <snip>
> > PE=0 Dbit=0 (un)Real Mode
> > PE=0 Dbit=1 Forreal Mode
> > PE=1 Dbit=0 Veal Mode (BKA "286 task")
> > PE=1 Dbit=1 Protected Mode
>
> These would be better clarified using standard nomenclature:
>
> PE=0 Dbit=0 16-bit Real Mode (and "unreal" mode)
> PE=0 Dbit=1 32-bit Real Mode (?)
> PE=1 Dbit=0 16-bit Protected Mode
> PE=1 Dbit=1 32-bit Protected Mode
>
> (?) I'm not sure if "32-bit Real Mode" is the proper nomenclature, but it is
> far more accurate than "Veal" and "Forreal" mode...
I discovered it, so my name for it is accurate. Veal Mode may really
properly be "286 Task" however, but I'm not up for understanding 286
tasks all that well, thankyouverymuch.
>
> <snip>
> > ... that IRET is really sensitive to the current effective
> > code size, of which the D bit is just one component.
>
> Good observation. But, I think most are aware of operand and address size
> prefixes and understand they can be used in every mode (other than 64-bit?).
Apparently I'm the only person in the world who can further see that
that lovely little bit of othogonality allows a fundamental and useful
mode of the 386 people like Chuck Moore might like.
>
> > Canonical Wake-up Real Mode [sic, Real Mode]
> > and Unreal Mode [sic, "unreal" mode] are two flavors of the same
> > basic setting of PE and Dbit. The difference is in segment limits.
>
> True.
>
> > This points up a basic concept here. 8086-style segments are
> > a lightweight layer that may or may not be active, but 386
> > segments are always active.
> > PE=0 does not turn them off. PE=0 means you can't change
> > them until you turn PE back to 1. PE should be called
> > "PCE, Protections Changes Enabled".
>
> And, that's an advantage and different from PE meaning "Protection Enabled,"
> how exactly?
It means "Protection Change Enabled". Which means protection can be off
in 32 bit mode. Big difference. Important difference. Sorry I didn't
flag that for you.
>
> > This means the four basic modes have a state diagram about like so...
>
> In addition to the non-standard terminology, your diagram doesn't show the
> changes in the D bit. Also, it appears that there is an error in your
> diagram (below). And, one needs a fixed-width font to view it properly...
>
Thanks for pointing out that last bit.
When you see 'far xfer to use16' or use32, think (changes D-bit), eh?
Between Veal Mode and PMode, in the diagram. Since those two have
different D-fault code sizes.
Shown. In the diagram.
:-/
Yes.
>
> > You can interrupt between pmode [sic, 32-bit Protected
> > Mode] and Veal Mode [sic, 16-bit Protected Mode].
> ...
> > Conversely, events in rmode [sic, 16-bit Real Mode]
> > or Forreal Mode [sic, 32-bit Real Mode] (PE=0)
> > have to be handled in the mode they occur in.
>
> Okay, so what you are saying is: 'PM can execute both 16-bit and 32-bit code
> segments, unlike RM where only 16-bit or 32-bit code segments can be
> executed exclusively.' I'm not completely sure about that or this, but I
> think the Intel manuals state that...
I'm saying that 8086 segments aren't 386 segments, and they can coexist
(Veal Mode, BKA 286 Tasks), both be non-existant (Forreal Mode), or be
one-only, i.e. 386 segments only ( PMode), or 8086 segments only ( Real
Mode). The orthogonality of other-operator-size prefix allows the
only-one cases.
The Intel Manual doesn't say that.
>
> > The above diagram does not account for different segment limits and
> > bases than those in effect in WakeUp Rmode [sic, 16-bit Real Mode],
> > so e.g. unreal mode is not shown.
> > This chart also does not account for V86 Mode, which basically
> > requires 386 task-switch constructs. The above modes and
> > transitions do NOT need a TSS, or paging. I suspect V86 could
> > run off Veal Mode [sic,16-bit Protected Mode] OR
> > pmode [sic,32-bit Protected Mode].
> >
> <snip>
>
> > The following (osimplay) code demonstrates the superficiality of 8086
> > "schmegments" vis-a-vis 386 segments, even when PE=0...
>
> Even as an American, I appreciate the allusion to "Red Dwarf," but I suspect
> it will be lost on many... "Smeg" was used in the TV show as a expletive
> substitute.
>
> <snip>
Convergent devolution, I'm afraid.
>
>
> Rod Pemberton
Let me put it another way; code size segments are different from, and
orthogonal to, protection segments. Code size is 16-or-32, and
protection is on-or-off, and the four possible states of those two
binary variables form 4 major modes. One is previously unknown, or I
suspect, Chuck Moore would have used it for ColorForth.
All snot aside, thanks for clarifying what I need to clarify. This
ain't easy.
RIck Hohensee
Rod Pemberton
>
> Rod Pemberton wrote:
> > "humbubba" <hohens...@yahoo.com> wrote in message
> > news:1159283228.0...@d34g2000cwd.googlegroups.com...
over
> > and over again, over a number of years, to various NGs?
> >
> I'm very flattered you remember posts from , what, two years ago?
Sorry, I didn't mean to imply that I read it then. I'm a very aggressive
user of Yahoo search and Google's Groups search. I probably ran across it
with a FORTH related search.
> I discovered it, so my name for it is accurate. Veal Mode may really
> properly be "286 Task" however, but I'm not up for understanding 286
> tasks all that well, thankyouverymuch.
>
Fair enough. I found your post to be interesting, but, I think the reasons
you seem get low responses to your post on this are:
1) assembly programmers have no idea what you're talking about, i.e.,
non-standard nomeclature and EE concepts
2) FORTH and C programmers have no idea what you're talking about, i.e.,
it's not FORTH or C
3) eletrical engineers (EE's) knowledgeable of the circuitry used to
implement all of this aren't where you posted...
4) you're posting to groups that have no interest in this (alt.politics,
linux.kernel)
5) you're posting to low usage groups (alt.os.assembly)
Since this conversation has many sides: electrical engineering, assembly,
FORTH, I'd definately try some other groups. If you're interested in more
responses on the assembly language side of this conversation, you could try
posting to alt.lang.asm or comp.lang.asm.x86 (moderated).
> > > ... that IRET is really sensitive to the current effective
> > > code size, of which the D bit is just one component.
> >
> > Good observation. But, I think most are aware of operand and address
size
> > prefixes and understand they can be used in every mode (other than
64-bit?).
>
> Apparently I'm the only person in the world who can further see that
> that lovely little bit of othogonality allows a fundamental and useful
> mode of the 386 people like Chuck Moore might like.
>
Perhaps, but if you look outside the FORTH area, you'll notice that many of
the iconic individuals in programming areas intensely prefer their own
private space and reality and vehemently refuse to accept direction, advise,
or input from others. Some are strong at promoting their cause and others
just let things be.
If it is useful to FORTH, or another language such as C, or some programming
tool, you or a crew you assemble (pun intended) will need to bring it into
reality.
Also, I recently had conversations with David Lunt on alt.os.development
over his "FYS" OS: Konan. He wrote portions of his OS in "unreal" mode
including enabling the A20 line. After many problems trying to get the code
to work on one machine of mine, he eventually just moved the A20 code
outside of "unreal" mode. Although the A20 code works now, his OS still
doesn't work on that machine, which I suspect is due to his usage of
"unreal" mode. Just an FYI or warning about undocumented stuff...
> When you see 'far xfer to use16' or use32, think (changes D-bit), eh?
Oh, yup, but that isn't as clear. And, attempting to mentally integrate the
prior table information with the diagram when things don't seem clear...
more confusion.
Which reminds me, PM doesn't actually enable until CS is loaded with a
selector.
> > > Interesting. Forreal Mode [sic, 32-bit Real Mode] is the
> > > furthest from Wake-up [sic, 16-bit Real Mode], and you
> > > can only get to Forreal Mode [sic, 32-bit Real Mode] from
> > > pmode [sic, 32-bit Protected Mode]. Forreal Mode
> > > [sic, 32-bit Real Mode] is like a back room off of pmode
> > > [sic, 32-bit Protected Mode].
> >
> > If true, I find it interesting that one can't just switch from 16-bit
Real
> > Mode to 32-bit Real Mode [i.e., Forreal] like the other mode. Are you
sure
> > you aren't "combining" the effects of "unreal" mode (big segments for
Real
> > Mode) and 32-bit Real Mode?
>
> Yes.
Have you looked into what fails if you attempt to go directly from 16-bit
Real Mode [i.e., Wake-up] to 32-bit Real Mode [i.e., Forreal]? Is it only
certain instructions that fail or what doesn't seem to work? Also, have you
found out why must one go through two forms of PM to get to it?
Rod Pemberton
idk...@gmail.com
>
> Rod Pemberton
As one who has read the original Intel books for the 3886 processor,
This post and the one you replied to were quite understandable;
I'm a c, forth and asm coder and I had no problem following along.
I remark only because your first and second points were general
statements
and I'm sure there are folks here or somewhere else who would
understand
the source post.
But thanks anyhow for the repsonses.
humbubba
Thanks to both of you. I'm sure Pemberton has a point, in that not
everyone is a C, Forth and assembly programmer. Whereas you are, you
might find osimplay interesting. That's the assembler I did in Bash.
All Bash. No toolchains. I think osimplay's relative clarity helped me
figure out forreal mode. A Linux kernel guy said it looked like the
bastard love-child of a drunken encounter between APL and that gag
language that requires a 'please' operator now and then. AH! INTERCAL.
I take that as high praise for a 386 assembler.
:o)
"""
At noon on the day after this Amendment is ratified the occupants of
the offices of President and Vice President shall be removed, and
replaced for the remainder of the 2005-2009 term by Richard Allen
Hohensee, President, and Senator Russell Feingold, Vice President. This
replacement and term shall be supported by a special chain of
succession composed of random drawings from all those Senators and
Representatives who voted against the joint resolution allowing the
invasion of Iraq.
"""
See the second line of my .sig for osimplay, the Forreal demo tgz and
so on.
Rick (Richard Allen) Hohensee
linux01.gwdg.de/pub/cLIeNUX/interim
http://linux01.gwdg.de/~rhohen
http://groups.google.com/groups/search?hl=en&q=rick+hohensee&qt_s=Search