Searching \ for '32 vs. 16 bit O/S code [Was: MPLAB with HP Palmtop' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/languages.htm?key=mplab
Search entire site for: '32 vs. 16 bit O/S code [Was: MPLAB with HP Palmtop'.

Truncated match.
PICList Thread
'32 vs. 16 bit O/S code [Was: MPLAB with HP Palmtop'
1997\08\03@034251 by Clyde Smith-Stubbs

flavicon
face
There is an awful lot of misinformation being spread on this thread.
The 16 vs. 32 bit distinction on Intel x86 processors is as follows:

80x86 processors up to the '286 are 16 bit only - they have 16 bit wide
accumulators and index registers, and a limit of 64K per addressable
segment.

The 386 and higher processors have split personalities; they are effectively
two processors in one. The distinction comes about only when running in
protected mode, and is made by distinguishing two types of segments - 16
bit segments operate just like a 286, 32 bit segments operate like a
quite different processor; in 32 bit segments the available register set
is different (all 32 bit not 16 bit) and the set of addressing modes
is *totally* different (note; it is possible to have 32 bit instructions
in a 16 big segment or vice versa, by use of override prefixes).

In a 32 bit O/S like NT or Linux, the operating system code runs in 32
bit segments, and uses "flat" model code, where a linear 32 bit address
space is used. In a 16 bit O/S like Win3.1, the O/S code mostly runs
in 16 bit segments, using segmented addressing. Win95 is a hybrid; some
32 bit code, quite a lot of 16 bit code.

When it comes to applications under Windows, there is not only the distinction
between 16 and 32 bit code, but also the distinction between the Win16 API
and the Win32 API. While the Win32 API is superficially a superset of Win16,
there are major extensions, and fundamental differences that, amongst other
things, make it possible for Win32 programs to be pre-emptively task-switched,
whereas Win16 programs in the same virtual machine can only be co-operatively
task switched.

Win95 and WinNT both support both the Win16 and Win32 API, but only Win32
applications task switch cleanly (all Win16 apps in NT are treated together
as one Win32 task, and within that task the Win16 apps do not pre-emptively
task switch - though it is possible to have additional Win16 (aka Windows On
Windows
or WOW) virtual machines running, but it's very memory hungry).
Win

On Sun, Aug 03, 1997 at 02:52:27AM -0400, Mike wrote:
>
> Sorry - no such thing as a true 32 bit operating system - what is the
> collective definition of a 16 or 32 bit operating system ANYWAY ???

A 32 bit O/S is one that runs natively on a 32 bit processor. NT fits this
definition. Win3.1 does not, Win95 might do.

> It may not load a 16bit dll 'app' BUT I would be willing to bet it is
> riddled with 16 bit code since its more efficient to selectively use
> 16 bit instructions when its just a complete waste of resources to try

Wrong! On an x86 processor in 32 bit mode, 16 bit addressing (i.e. using
a 16 bit index register or even loading a 16 bit register) is very
inefficient, due to the prefix byte required to force 16 bit addressing. In
this mode, 32 bit addressing is much more efficient. And 32 bit mode is
more efficient than 16 bit mode since the flat model eliminates the
very costly segment register loads required by the 16 bit segmented model
used in 16 bit mode. Any memory intensive 32 bit code will run much faster
than 16 bit code that has to address more than 64K memory.

Cheers, Clyde

--
Clyde Smith-Stubbs  |HI-TECH Software,      |Email: spam_OUTclydeTakeThisOuTspamhtsoft.com
Ph:  +61 7 3354 2411|P.O. Box 103, Alderley,|WWW:  http://www.htsoft.com/
Fax: +61 7 3354 2422|QLD, 4051, AUSTRALIA.  |PGP: finger .....clydeKILLspamspam@spam@htsoft.com
---------------------------------------------------------------------------
ANSI C for the PIC! Now shipping! See http://www.htsoft.com for more info.

1997\08\03@040326 by Mike

flavicon
face
At 05:41 PM 8/3/97 +1000, you wrote:

Hi Clyde,
Thanks for clarifying the preliminaries re apps etc

{Quote hidden}

mmm - I'm not so sure. I remember seeing this sort of debate some time ago
when Win95 first came out at that time I was shown code snippets in
'true' 32 bit mode and 'hybrid' which had about 70% in NON 32 bit mode,
I think the data structures being operated on were around the 64K sixe,
since that involved a peculiarity of the processor.

I seem to recall that the 'true' 32 bit code was slower and occupied more
space than 'selectively' preparing the appropriate segment registers, doing
the required operations in NON 32 bit mode, then cleaning up the various
segment registers at the end - OVERALL the 16 bit code was faster and about
20% smaller. There was apparantly no way the task could be put into
32 bit only mode AND have it run faster or be smaller. The task had a lot
to do with 'real world' data processing and preparing output for display.
I'll try and dig this up, but it was about 15 months ago...

So - would you suggest that in NT (ignore 16 bit ported app/dlls) every single
instruction operates on the 32 bit model and there are no 16 bit instructions
or other instructions which are less than a 32 bit 'lump', frankly I
can't see how you could write an OS which ONLY had 32 bit instructions on
the 486/Pentium processor - there must be some 8/16 bit instruction - at
least in terms of word size - is there a 32bit IO space as well as memory
address space - and would you want that ?

Rgds

Mike

1997\08\03@050636 by Clyde Smith-Stubbs

flavicon
face
On Sun, Aug 03, 1997 at 04:03:26AM -0400, Mike wrote:
> At 05:41 PM 8/3/97 +1000, you wrote:

> I seem to recall that the 'true' 32 bit code was slower and occupied more
> space than 'selectively' preparing the appropriate segment registers, doing

32 bit code tends to be smaller (because of better addressing modes) - if you
avoid doing any segment register loads, 16 bit code could execute as
fast as 32 - it's unlikely to be faster except in very exceptional
circumstances. In practice, any 16 bit Windows application will use
segment register loads, which really kills performance (each segment
register load actually loads several hidden registers from the segment
table).

> can't see how you could write an OS which ONLY had 32 bit instructions on
> the 486/Pentium processor - there must be some 8/16 bit instruction - at

Of course. The 8 bit addressing is still available in 32 bit mode, and
has no performance penalty, but trying to use 16 bit index registers is
costly, and offers no benefit (since the 386 and up have 32 bit data
buses anyway).

> least in terms of word size - is there a 32bit IO space as well as memory

Again, of course the address space is 32 bit - the external data bus
requires that. But there's no problem accessing data 8 bits at a time, it's
just you get a 32 bit address put out (though the external hardware may see
less than 32 bits).

--
Clyde Smith-Stubbs  |HI-TECH Software,      |Email: clydespamKILLspamhtsoft.com
Ph:  +61 7 3354 2411|P.O. Box 103, Alderley,|WWW:  http://www.htsoft.com/
Fax: +61 7 3354 2422|QLD, 4051, AUSTRALIA.  |PGP: finger .....clydeKILLspamspam.....htsoft.com
---------------------------------------------------------------------------
ANSI C for the PIC! Now shipping! See http://www.htsoft.com for more info.

1997\08\03@112135 by Griffith Wm. Kadnier

flavicon
face
Hi Mike,

1) As one of the original WinNT Kernel-Team developers @ MS from 1991-1993,
and then as a Kernel-Team developer, porting 32 bit elements of NT to
Windows95, for that group, I can tell you absolutely that WinNT uses NO 16
bit code in it's 32 bit-OS data paths. Almost 100% of the base OS is C/C++
(except elements of the HAL, where some assembler is used), and is/has been
compiled using MS's 32 bit compilers. The upper-edge WOW, and DOS VDM
routines are the only part of NT that even KNOW about 16 bit code, and
these elements can be looked at as add-ons, for backwards compatibility.

I think that scenario suffices for a definition of a 32 bit operating
system :}

See my book "Windows NT4, The Complete Reference"-Osborne McGraw-Hill ISBN
0-07-882181-9, for a sysadmin-level discussion of NT's 32 bit architecture,
vis-a-vis the Kernel, GDI, drivers, etc.

Windows 95, on the other hand, has many 16 bit elements, cooperating
(hopefully) with it's 32 bit layers. (I don't think 95% is anywhere near
correct though)--The Win95 User/Kernel is probably less than 20-30%
dependent upon 16 bit code, and ALL ancillary VxD's are 32 bit. Some of the
OS routines thunk down to a base-16 bit routine, and that, among other
issuses, is where you take a hit.


2) That said, it must also be noted that comments in prior msg's linked to
this thread, about 8/16 bit quantities or accesses being ineffeciently
handled by a 32 bit-wide instruction stream, are equally fallacious. It
does NOT take 32 bits to store an 8 bit memory or port quantity. The
instruction may be 32 (or more) bits wide, and memory addresses will be 32
bits, but a byte is still a byte in 32 bit land, and memory access can be
done with equal effeciency on 32 bit intel processors that contain
instructions to read, write, and do I/O on byte, word, double-word, and
quad-word basis, given that the electronic architectures are equal.

Also, a data structure gets only the space that is allocated for it by a
compiler or at the asm level. A 4 gb address space is NOT automaticlly
given to ANY process, and certainly not to an arbitrary data structure
within a process; that is the responsibility of the OS memory management
that is in charge; the part of the underlying software that is actually
handling memory and process allocation on behalf of an upper-level process.

3) The memory space of the Pentium family is 4 gb. The I/O space of the
Pentium family is 64k.
Memory is actually organized in 64 bit chunks, with byte-sized sub-unit
addressing. I/O is organized as sequences of 32 bit quantities,  accessable
as byte sub units. It is up to the computer maker to organize these base
schemes in terms of access to 64, 32, 16, or 8 bit I/O or memory planes.

4) Clyde is also right in his assertion that 16 bit code is *usually* less
effecient on a 32 bit CPU. Selector loads, and indexing are always less
effecient than flat model. BUT, the responsibility to use 32 bit
instructions and address space for the most efficient data movement is
++always++ put squarely upon the programmer and/or the compiler used. I
know of a lot of very SLOWWW code being produced by programmers that don't
know/care how their compiler works. (How about passing whole C++
objects...not pointers, around on the stack??....Do you want to see what
repeated setup/teardown of a 512K deep stack does to the operation of a
process???) This kind of stuff would only be worse in a 16 bit environment.
Applications (and OS code) always rise to the level of the incompetecy of
their creators!

I'd love to get down to Australia sometime. I hear it's the land to be in
for us Liberatarians-at-heart.

gwk
Algorithmics Inc.
----------
> From: Mike <EraseMEerazmusspam_OUTspamTakeThisOuTWANTREE.COM.AU>
> To: PICLISTspamspam_OUTMITVMA.MIT.EDU
> Subject: Re: 32 vs. 16 bit O/S code [Was: MPLAB with HP Palmtop windows
CE]
{Quote hidden}

In
> >this mode, 32 bit addressing is much more efficient. And 32 bit mode is
> >more efficient than 16 bit mode since the flat model eliminates the
> >very costly segment register loads required by the 16 bit segmented
model
> >used in 16 bit mode. Any memory intensive 32 bit code will run much
faster
> >than 16 bit code that has to address more than 64K memory.
>
> mmm - I'm not so sure. I remember seeing this sort of debate some time
ago
> when Win95 first came out at that time I was shown code snippets in
> 'true' 32 bit mode and 'hybrid' which had about 70% in NON 32 bit mode,
> I think the data structures being operated on were around the 64K sixe,
> since that involved a peculiarity of the processor.
>
> I seem to recall that the 'true' 32 bit code was slower and occupied more
> space than 'selectively' preparing the appropriate segment registers,
doing
> the required operations in NON 32 bit mode, then cleaning up the various
> segment registers at the end - OVERALL the 16 bit code was faster and
about
> 20% smaller. There was apparantly no way the task could be put into
> 32 bit only mode AND have it run faster or be smaller. The task had a lot
> to do with 'real world' data processing and preparing output for display.
> I'll try and dig this up, but it was about 15 months ago...
>
> So - would you suggest that in NT (ignore 16 bit ported app/dlls) every
single
> instruction operates on the 32 bit model and there are no 16 bit
instructions
> or other instructions which are less than a 32 bit 'lump', frankly I
> can't see how you could write an OS which ONLY had 32 bit instructions on
> the 486/Pentium processor - there must be some 8/16 bit instruction - at
> least in terms of word size - is there a 32bit IO space as well as memory
> address space - and would you want that ?
>
> Rgds
>
> Mike

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...