Hello all,

I dont understand why there are still 16 bit programms for x86 ? (like DOS etc)
Why is there still a protected and real mode in processors like x86 ?
What is the use ?

thanks

Can you define "still"? Most of the 16-bit programs are legacy apps. Hardly anyone develops new 16-bit apps anymore. The sole exception to this is a bootloader. And this is due to backward compatibility on the newer processors as they start in real mode by default.

hi ugenn,
I still dont understand.
why the x86 have kept that crappy real mode ?
why the x86 processor needs to start with real mode ?
and when I need to access bios datas in protected mode, how do I do that ?
do I need to write a 16-bit app in assembly ?

why the x86 have kept that crappy real mode ?
Backward compatibility.

why the x86 processor needs to start with real mode ?
Backward compatibility.

and when I need to access bios datas in protected mode, how do I do that ?
do I need to write a 16-bit app in assembly ?

Depends on the OS. Some of the "well-known" (eg keyboard buffer, VGA video ram etc) real mode addresses may be mapped to some virtual 32-bit address. CMOS data can also be accessed through the IO ports 0x70-75 (not too sure).

Depends on the OS. Some of the "well-known" (eg keyboard buffer, VGA video ram etc) real mode addresses may be mapped to some virtual 32-bit address. CMOS data can also be accessed through the IO ports 0x70-75 (not too sure).
how do I do when the data I need is not mapped ?

Huh? What do you mean?

one simple question :
can we access the whole BIOS through mapped memory ? If not, how to do it ?
backward compatibility is useless for 80x86 and that makes them more complicated and badly designed.

one simple question :
can we access the whole BIOS through mapped memory ? If not, how to do it ?

The memory area used by the BIOS (the first 384k of RAM) can be accessed in protected mode if you're able to get a virtual memory mapping to that address range. CMOS is typically accessed from those ports I mentioned. The BIOS interrupts, OTOH are usually unaccessible from most protected mode systems as these are real mode code. Protected mode OSes will usually replace the BIOS calls with their own drivers/code.

backward compatibility is useless for 80x86 and that makes them more complicated and badly designed.

Another of your blanket statements. Yes, real mode is klunky and ugly, but do a little more research on why backward compatibility is important.

Besides, with most protected mode OS, you don't have to worry about real mode at all. It is simply not an issue.

[QUOTE]Originally posted by ugenn
The memory area used by the BIOS (the first 384k of RAM) can be accessed in protected mode if you're able to get a virtual memory mapping to that address range. CMOS is typically accessed from those ports I mentioned. The BIOS interrupts, OTOH are usually unaccessible from most protected mode systems as these are real mode code. Protected mode OSes will usually replace the BIOS calls with their own drivers/code.

So how do I access BIOS datas if I am running on protected mode and there is no memory mapping or OS driver call to these datas ?

backward compatibility is useless for 80x86 and that makes them more complicated and badly designed.
Another of your blanket statements. Yes, real mode is klunky and ugly, but do a little more research on why backward compatibility is important.

About x86 bad design : just search internet or books, you will find it easily. I find it strange you didnt know that ?

x86 is bad designed because :
-x86 hasnt enough registers.
-x86 has variable length instructions,
-x86 has mem to mem operands,
-x86 has complex addressing modes,
etc.

Some quotes :

David J. Ruck :
"Hand coding optimally for the PIII class of processors is an unbelievable difficult task, more so than probably any other architecture.
The Pentium isn't an really x86 processor, its a hardware emuation of one using multiple and asymetric RISC sub cores. It takes the massively badly designed x86 ISA (few registers, variable length instructions, mem to mem operands, complex addressing modes) and dynamically translates these in to fixed lengh RISC instructions using two decode units for dispatch to up to 5 asymetric ALUs. It also uses the very complex techniques of branch prediction, speculative execution, out of order execution, register renaming and multiple reorderd retirement.
To write optimal assember you have to know the vagarities of pairing instructions as the decode units and ALUs are all asymetric, and each part of the chip has different throughput charactistics which can lead to multiple stalls if the instruction mix is not tightly balanced. Code alignment can effect issues such as cache hit rates and decode throughput, loop counts can effect branch predication. Its a nightmare for hand crafting and assemblers alike.
The PIII really is the most increadly feat of design, and so bloody pointless just work around the failings of a ISA which was badly designed 20 years ago and bodged on top of every since. Compared with the PIII the StrongARM is a couple of transistors on a bit of veroboard, and even the new XScale hasn't needed a tenth of the tricks used on the Pentium to achive the equivelent performance."

Chung-Hsiung Yang :
"x86 architecture has been acknowledge by anyone who knows anything about computer architecture as the most successful *badly* designed processor history has ever seen. So what of it. There are plenty of great processors that have been designed in the past that have turned out to be utter failures. What I am saying is massive amont of R&D dollar doesn't necessary mean a wildly successful product."

Steven C. Den Beste :
" "Make it better!" the customers cried, and "Keep it backwards compatible!" cried marketing at Intel." (...) I remember how this macro compatibility was ballyhooed by Intel's marketing, but I don't recall hearing of anyone who took advantage of it. (...) Motorola had the 6800 which competed with the 8080, and when they began the 68000 design they made no pretense whatsoever to maintaining backward compatibility with it. Instead, they did a complete clean design for a 32-bit CPU, then implemented the whole thing in 16-bits."

Besides, with most protected mode OS, you don't have to worry about real mode at all. It is simply not an issue.
And when you code a bootloader ? How do you do that ?
And when writing some specific drivers ?
And also when writing assembly ?

[QUOTE]Originally posted by programmershous
So how do I access BIOS datas if I am running on protected mode and there is no memory mapping or OS driver call to these datas ?


If the OS doesn't allow you to access it, then you can't. That's why it's called protected mode. This sort of behavior isn't unique to x86. All CPUs that are capable of pmode exhibit this sort of behavior.

About x86 bad design : just search internet or books, you will find it easily. I find it strange you didnt know that ?

I specifically said it (with "it" being real mode) was klunky and ugly, didn't I? However, I also did say that backward compatibility is necessary.

x86 is bad designed because :
-x86 hasnt enough registers.
-x86 has variable length instructions,
-x86 has mem to mem operands,
-x86 has complex addressing modes,
etc.

What's your point exactly? That x86 design is bad? Or that real mode is bad? Because all the above apply in 32-bit pmode as well.
These points you mentioned are more about RISC vs CISC archititectures. Nothing to do with real mode vs pmode. BTW, lack of registers aren't really an issue on x86. Because unlike most other CPUs which require a load/store mechanism, x86 allows direct manipulation of memory w/o having to first load it into a register.

Besides, with most protected mode OS, you don't have to worry about real mode at all. It is simply not an issue.
And when you code a bootloader ? How do you do that ?
And when writing some specific drivers ?
And also when writing assembly ? [/B]

With the exception of the bootloader, all the other stuff you mentioned need not concern themselves with real mode. All modern OSes on the x86 run in pure pmode.