Sorry if this is Off topic, but I didn’t know who else to ask…
Y are processors still made back ward compatible to the extent of 16 bit
code support? Why do we still bootstrap in 16 bit modes when DOS based
programs are long obsolete?
Can’t the support be dropped now?
–
Why don’t you ask why IBM mainframes still have mid-1960’s instruction
sets, support DOS 360 which was obsoleted 40 years ago, and still come with
an emulator for 1401’s that were obsolete in 1959?
The 16 bit instruction set is still used and is part of the 32-bit and
64-bit set. Intel has been pushing EFI to replace the old boot, I
understand it has gotten better, when I first tried it roughly 5 years ago,
I found the 10 minutes to logon a mite excessive.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply
“amitr0” wrote in message news:xxxxx@ntdev…
> Sorry if this is Off topic, but I didn’t know who else to ask…
>
>
> Y are processors still made back ward compatible to the extent of 16 bit
> code support? Why do we still bootstrap in 16 bit modes when DOS based
> programs are long obsolete?
>
> Can’t the support be dropped now?
>
> –
>
> - amitr0
>
amitr0 wrote:
Y are processors still made back ward compatible to the extent of 16
bit code support? Why do we still bootstrap in 16 bit modes when DOS
based programs are long obsolete?
They may not be important TO YOU, but I can assure you that DOS-based
programs are far from obsolete. If Intel stopped supporting 16-bit
instructions in their processors, they would lose customers.
Remember that the 8-bit Z-80 is still being sold in vast numbers today.
It doesn’t run Windows, but that doesn’t matter to the people who use it.
Can’t the support be dropped now?
Dropped from what? You need to remember that Windows-based computers
are only part of the market for processors. Sure, your Windows computer
could boot straight into 32-bit protected mode without giving up very
much, but there are many applications for processors in the world
besides Windows.
Win64 does not support 16-bit programs.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Anyone know of any FREE versions of DOS that support NTFS read/write?
I’ve seen freedos, but I don’t
recall it supporting ntfs. I also seem to recall sysinternals selling a
product that did something similar - I think it added
NTFS to win95 and 98 though…
Looking for DOS though - it would be nice.
amitr0 wrote:
Sorry if this is Off topic, but I didn’t know who else to ask…
Y are processors still made back ward compatible to the extent of 16
bit code support? Why do we still bootstrap in 16 bit modes when DOS
based programs are long obsolete?Can’t the support be dropped now?
–
- amitr0
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Once Intel designed some i386 based microcontrollers for embedded
market, that booted directly to protected mode and did not have any
real mode or 16-bit compatibility.
It seems that 16 bit instruction set is not too much of burden for a
workstation processor, and there is no strong motivation to dump it.
Regards,
–PA
“amitr0” wrote in message news:xxxxx@ntdev…
> Sorry if this is Off topic, but I didn’t know who else to ask…
>
>
> Y are processors still made back ward compatible to the extent of 16 bit
> code support? Why do we still bootstrap in 16 bit modes when DOS based
> programs are long obsolete?
>
> Can’t the support be dropped now?
>
> –
>
> - amitr0
>
Am I wrong that x64 dropped the 16bit code support?
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
“Don Burn” wrote in message news:xxxxx@ntdev…
> Why don’t you ask why IBM mainframes still have mid-1960’s instruction
> sets, support DOS 360 which was obsoleted 40 years ago, and still come with
> an emulator for 1401’s that were obsolete in 1959?
>
> The 16 bit instruction set is still used and is part of the 32-bit and
> 64-bit set. Intel has been pushing EFI to replace the old boot, I
> understand it has gotten better, when I first tried it roughly 5 years ago,
> I found the 10 minutes to logon a mite excessive.
>
>
> –
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> http://www.windrvr.com
> Remove StopSpam from the email to reply
>
>
>
> “amitr0” wrote in message news:xxxxx@ntdev…
> > Sorry if this is Off topic, but I didn’t know who else to ask…
> >
> >
> > Y are processors still made back ward compatible to the extent of 16 bit
> > code support? Why do we still bootstrap in 16 bit modes when DOS based
> > programs are long obsolete?
> >
> > Can’t the support be dropped now?
> >
> > –
> >
> > - amitr0
> >
>
>
>
Very probably, Pentium machines still supported 8 bit op-codes that go all the way back to a glue logic state machine invented by datapoint around '63 it became the basis for the Intel 8008 the world first single chip 8 bit microprocessor, in turn those op-codes were handed down to the 8080, Z80 & 8085 in that order. When Intel designed the 8088/8086 for the first PC’s they dropped 8 of those 56 older op-codes since the “restart” instructions were branches into low ram where the old (now antique) dos-mode interrupt vector table now resides. I am not supprised if code written back in '63 for a machine controller will run on the new 64 bit hardware. DBB
Maxim-
> Am I wrong that x64 dropped the 16bit code support?
Pasted directly from the Intel system programming manual (hopefully I haven’t violated a copyright in the process):
All Intel 64 and IA-32 processors enter real-address mode following a power-up or
reset (see Chapter 9, “Processor Management and Initialization”).
However, Windows does not support any 16-bit modes in any 64-bit OS version.
It all depends upon how you want to parse the question.
xxxxx@xitron.com wrote:
Very probably, Pentium machines still supported 8 bit op-codes that go all the way back to a glue logic state machine invented by datapoint around '63 it became the basis for the Intel 8008 the world first single chip 8 bit microprocessor, in turn those op-codes were handed down to the 8080, Z80 & 8085 in that order. When Intel designed the 8088/8086 for the first PC’s they dropped 8 of those 56 older op-codes since the “restart” instructions were branches into low ram where the old (now antique) dos-mode interrupt vector table now resides. I am not supprised if code written back in '63 for a machine controller will run on the new 64 bit hardware.
Oh, the AMD64 and EM64T processor architectures certainly support 16-bit
code (as witness by the fact that Win32 runs unchanged), but the Win64
operating systems do not. It’s an operating system thing, not a
processor thing. You cannot load a 16-bit executable in a Win64 DOS box.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Indeed,
even if the op-sys fails to support it it may still be do-able however there comes a point where you must ask is it worth it ?, can’t you get 64 bit mode versions of the code you need or if you must have 16 bit mode operations will kicking it down to 16 bits totaly blow the op-sys to pieces upon the next interrupt ?. Maybe you can hold your breath for a 16 bit mode emmulator like the windows emmulator on Mac platforms ?
wrote in message news:xxxxx@ntdev…
> Indeed,
> even if the op-sys fails to support it it may still be do-able however
> there comes a point where you must ask is it worth it ?, can’t you get 64
> bit mode versions of the code you need or if you must have 16 bit mode
> operations will kicking it down to 16 bits totaly blow the op-sys to
> pieces upon the next interrupt ?. Maybe you can hold your breath for a 16
> bit mode emmulator like the windows emmulator on Mac platforms ?
>
You are confusing 16-bit instructions and 16 bit environments. All the
compilers out there will still issue a 16-bit, or 8-bit instruction if that
is the needed size of the operation. Note: C as a language does promotion
to integer types most of the time, but there are other languages in use
where doing a 16 bit operation is required for a 16-bit type (and they have
real fun on RISC where everything is done to register sizing).
Now whether the 16-bit environments are needed could be argued, but at the
present time this would break most of the OS loaders if you threw that out!
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
I’m sorry if you misunderstood my last posting but I confused nothing !. When it comes to blasting a Microsoft op-sys to pieces I am truly guru level. I have over 10k hours of macro assembler & hand compiled machine code to my credit on more machines then I care to remember and your last comment overlooks something importent there are no “16 bit instructions” as such on pentium based CPU’s they have a mode switch that changes how the CPU interprets the op-codes the same instruction will operate on 16, 32 or 64 registers depending on the current CPU mode while 8 bit operations run the same mode not withstanding.
If you change the mode to run 16 bit operations you must prevent ANYTHING written for other modes from running or the CPU will mis-interpret the codes - if ANY interrupts on the machine fail to explicitly set the mode as needed then changing modes will cause them to run in the wrong mode if they occur while your code in running. Microsoft sets the mode as the first operation in their interrupt service routines BUT if you mount any TSR stuff to modify the way a 16 system behaves it will probably crash the machine since all that old DOS stuff was written before the mode switch even existed.
Also the 16 bit service calls aren’t going to be there for you so you must write all new code to replace them or adapt them to your 16 bit stuff !, this is no small chore & would depend on info Microsoft holds private so a big part of that would be hacking 64 bit Vista’s bottom-level support stuff. Sure you COULD write some kind of shell to run 16 bit stuff under but it would be a huge effort it’s the kind of project that may cost 1 or more programmers for over a year.
Better yet industrial suppliers still sell retrograde machines that can run antique code - you could tie them to Vista machines via RS232 cable-net assuming you really even need Vista-64.
So again I ask you what’s it worth ?
wrote in message news:xxxxx@ntdev…
> I’m sorry if you misunderstood my last posting but I confused nothing !.
> When it comes to blasting a Microsoft op-sys to pieces I am truly guru
> level. I have over 10k hours of macro assembler & hand compiled machine
> code to my credit on more machines then I care to remember and your last
> comment overlooks something importent there are no “16 bit instructions”
> as such on pentium based CPU’s they have a mode switch that changes how
> the CPU interprets the op-codes the same instruction will operate on 16,
> 32 or 64 registers depending on the current CPU mode while 8 bit
> operations run the same mode not withstanding.
> If you change the mode to run 16 bit operations you must prevent ANYTHING
> written for other modes from running or the CPU will mis-interpret the
> codes - if ANY interrupts on the machine fail to explicitly set the mode
> as needed then changing modes will cause them to run in the wrong mode if
> they occur while your code in running. Microsoft sets the mode as the
> first operation in their interrupt service routines BUT if you mount any
> TSR stuff to modify the way a 16 system behaves it will probably crash
> the machine since all that old DOS stuff was written before the mode
> switch even existed.
First, there are instructions yes you have to set the mode, or use the
prefix instruction to overide the mode, but as somebody who ran a code
generator group that was used by a heck of a lot of x86 compilers, there is
for any reasonable definition “16-bit instructions”. It is also the case
that for every OS supporting 32-bits or more, that the handling of the mode
in the face of interrupts, system calls or task switches is part of the
defined interface.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
> Why do we still bootstrap in 16 bit modes when DOS based
programs are long obsolete?
Simply because CPU has no concept of virtual memory when it gets powered on - switching it to the protected mode has to be done by the software, and, in order to be able to do it, software must be able to run somehow. Therefore, CPU has no option, other than operating in the real mode at the boot time - it has nothing to do with OS that is installed on the machine
Anton Bassov
xxxxx@hotmail.com wrote:
> Why do we still bootstrap in 16 bit modes when DOS based
> programs are long obsolete?
>Simply because CPU has no concept of virtual memory when it gets powered on - switching it to the protected mode has to be done by the software, and, in order to be able to do it, software must be able to run somehow. Therefore, CPU has no option, other than operating in the real mode at the boot time - it has nothing to do with OS that is installed on the machine
Well, this is all strictly an artifact of the IBM PC heritage. There is
nothing to prevent a BIOS from switching the processor into 32-bit
protect mode (which does not necessarily imply paging) in the boot
sector, and running everything in 32-bit land from that point on. It’s
all just convention, not requirement.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
You might as well ask why English (and French, German, Hindi, etc.) still contains words that people used 2000+ years ago.
Backward compatibility! It’s not some scourge, some evil. It simply means things have value, and people don’t throw valuable things away without a reason.
Besides, it’s not like 16-bit code is some huge burden on modern processor designers. Modern x86 processors are nothing, NOTHING like the little sequential processors of the early 80s. Only the front-end instruction decoder knows anything about the x86 instruction set, and it simply decodes it into an internal, intermediate language, which we never see. That instruction decoder is a tiny, tiny part of the overall processor. When you consider the complexity of a modern processor, the instruction decoder is basically negligible. These processors devote a huge amount of silicon to instruction-level parallelism – instruction reordering, register renaming, speculative execution, branch prediction, deep pipelining, multiple issue, etc. So who cares if the processor can still interpret 16-bit opcodes?
We used to think the instruction set matters… remember CISC vs. RISC? (Here’s a trick question – Is a modern x86 processor CISC or RISC?) In certain extremes, it does (like exotic vector architectures), but within the basic framework of low-processor count (including 1) commodity computers, it simply doesn’t matter. That’s why there’s really only one ISA any more, ignoring the modest x64 extensions, in the commodity workstation/server market.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Friday, February 16, 2007 5:48 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] 16 Bits Compatibility
Sorry if this is Off topic, but I didn’t know who else to ask…
Y are processors still made back ward compatible to the extent of 16 bit code support? Why do we still bootstrap in 16 bit modes when DOS based programs are long obsolete?
Can’t the support be dropped now?
–
For what it may or may not be worth, here are some stats from the Wikipedia
"microprocessor’ article:
===================
Market statistics
In 2003, about $44 billion (USD) worth of microprocessors were manufactured
and sold. [1] Although about half of that money was spent on CPUs used in
desktop or laptop personal computers, those count for only about 0.2% of all
CPUs sold.
About 55% of all CPUs sold in the world are 8-bit microcontrollers. Over 2
billion 8-bit microcontrollers were sold in 1997. [2]
So lets see. 10% of the micros are 32 bit or more and 2% of those end up in
PCs. So the 32+bit desktop market is 0.2% of the microprocessor market.
Even if we only care about 32+ bit processors, 98% of them end up in
refrigerators, toasters, and car stereos rather than on the desktop. Manybe
it is the 98% market share that should be at least partially driving the
feature content of the processors?
Loren
----- Original Message -----
From: “Arlie Davis”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, February 20, 2007 12:00 PM
Subject: RE: [ntdev] 16 Bits Compatibility
You might as well ask why English (and French, German, Hindi, etc.) still
contains words that people used 2000+ years ago.
Backward compatibility! It’s not some scourge, some evil. It simply means
things have value, and people don’t throw valuable things away without a
reason.
Besides, it’s not like 16-bit code is some huge burden on modern processor
designers. Modern x86 processors are nothing, NOTHING like the little
sequential processors of the early 80s. Only the front-end instruction
decoder knows anything about the x86 instruction set, and it simply decodes
it into an internal, intermediate language, which we never see. That
instruction decoder is a tiny, tiny part of the overall processor. When you
consider the complexity of a modern processor, the instruction decoder is
basically negligible. These processors devote a huge amount of silicon to
instruction-level parallelism – instruction reordering, register renaming,
speculative execution, branch prediction, deep pipelining, multiple issue,
etc. So who cares if the processor can still interpret 16-bit opcodes?
We used to think the instruction set matters… remember CISC vs. RISC?
(Here’s a trick question – Is a modern x86 processor CISC or RISC?) In
certain extremes, it does (like exotic vector architectures), but within the
basic framework of low-processor count (including 1) commodity computers, it
simply doesn’t matter. That’s why there’s really only one ISA any more,
ignoring the modest x64 extensions, in the commodity workstation/server
market.
------------------------------------------
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
Sent: Friday, February 16, 2007 5:48 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] 16 Bits Compatibility
Sorry if this is Off topic, but I didn’t know who else to ask…
Y are processors still made back ward compatible to the extent of 16 bit
code support? Why do we still bootstrap in 16 bit modes when DOS based
programs are long obsolete?
Can’t the support be dropped now?
–
- amitr0
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Most of the other uses for processors are very price sensitive. A car
manufacturer will go to extreme lengths to avoid a couple of dollars of cost
that they cannot reduce themselves. They can’t afford to add $300
processors to a car where that will increase the MSRP by $1200 each, if the
4x rule holds in non-computer hardware.
“Loren Wilton” wrote in message news:xxxxx@ntdev…
> For what it may or may not be worth, here are some stats from the
> Wikipedia "microprocessor’ article:
>
> ===================
> Market statistics
>
> In 2003, about $44 billion (USD) worth of microprocessors were
> manufactured and sold. [1] Although about half of that money was spent on
> CPUs used in desktop or laptop personal computers, those count for only
> about 0.2% of all CPUs sold.
>
> About 55% of all CPUs sold in the world are 8-bit microcontrollers. Over 2
> billion 8-bit microcontrollers were sold in 1997. [2]
>
> Less than 10% of all the CPUs sold in the world are 32-bit or more. Of all
> the 32-bit CPUs sold, about 2% are used in desktop or laptop personal
> computers, the rest are sold in household appliances such as toasters,
> microwaves, vacuum cleaners and televisions. “Taken as a whole, the
> average price for a microprocessor, microcontroller, or DSP is just over
> $6.” [3]
> ===================
>
> So lets see. 10% of the micros are 32 bit or more and 2% of those end up
> in PCs. So the 32+bit desktop market is 0.2% of the microprocessor
> market.
>
> Even if we only care about 32+ bit processors, 98% of them end up in
> refrigerators, toasters, and car stereos rather than on the desktop.
> Manybe it is the 98% market share that should be at least partially
> driving the feature content of the processors?
>
> Loren
>
>
>
> ----- Original Message -----
> From: “Arlie Davis”
> To: “Windows System Software Devs Interest List”
> Sent: Tuesday, February 20, 2007 12:00 PM
> Subject: RE: [ntdev] 16 Bits Compatibility
>
>
> You might as well ask why English (and French, German, Hindi, etc.) still
> contains words that people used 2000+ years ago.
>
> Backward compatibility! It’s not some scourge, some evil. It simply
> means things have value, and people don’t throw valuable things away
> without a reason.
>
> Besides, it’s not like 16-bit code is some huge burden on modern processor
> designers. Modern x86 processors are nothing, NOTHING like the little
> sequential processors of the early 80s. Only the front-end instruction
> decoder knows anything about the x86 instruction set, and it simply
> decodes it into an internal, intermediate language, which we never see.
> That instruction decoder is a tiny, tiny part of the overall processor.
> When you consider the complexity of a modern processor, the instruction
> decoder is basically negligible. These processors devote a huge amount of
> silicon to instruction-level parallelism – instruction reordering,
> register renaming, speculative execution, branch prediction, deep
> pipelining, multiple issue, etc. So who cares if the processor can still
> interpret 16-bit opcodes?
>
> We used to think the instruction set matters… remember CISC vs. RISC?
> (Here’s a trick question – Is a modern x86 processor CISC or RISC?) In
> certain extremes, it does (like exotic vector architectures), but within
> the basic framework of low-processor count (including 1) commodity
> computers, it simply doesn’t matter. That’s why there’s really only one
> ISA any more, ignoring the modest x64 extensions, in the commodity
> workstation/server market.
>
>
>
>
> ------------------------------------------
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of amitr0
> Sent: Friday, February 16, 2007 5:48 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] 16 Bits Compatibility
>
> Sorry if this is Off topic, but I didn’t know who else to ask…
>
>
> Y are processors still made back ward compatible to the extent of 16 bit
> code support? Why do we still bootstrap in 16 bit modes when DOS based
> programs are long obsolete?
>
> Can’t the support be dropped now?
>
> –
>
> - amitr0
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> Most of the other uses for processors are very price sensitive. A car
manufacturer will go to extreme lengths to avoid a couple of dollars of
cost that they cannot reduce themselves. They can’t afford to add $300
processors to a car where that will increase the MSRP by $1200 each, if
the 4x rule holds in non-computer hardware.
Its more like 6-10 to 1 for non-computer stuff. Somtimes as high as 20:1.
So yes, they really want to save dimes.
Loren
> computers, the rest are sold in household appliances such as toasters,
microwaves, vacuum cleaners and televisions. "Taken as a whole, the average
I’m amazed by the fact a microwave needs a 32bit CPU. Or are ARMs now so dirt
cheap that it is cheaper to use ARM in the microwave then the 8bit CPU?
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com