Segmentation in real mode
in [ASM]
|
Prev: stricmp
Next: Killing Explorer
From: Betov on 12 Mar 2005 06:36 Herbert Kleebauer <klee(a)unibwm.de> ýcrivait news:4232D11F.A23FD459 @unibwm.de: > Frank Kotler wrote:> > >> 32-bit programming, in itself, is *easier* than 16-bit >> programming - no worries about segments, and the addressing >> modes are much more flexible. Once you feel ready to make >> the switch (I'd learn how "call" and "ret" work - how to use >> the stack to pass parameters, and keep the stack "sane"), I >> think you'll like 32-bit programming... so don't waste *too* >> much time with dos! > > It is not fair to tell this old but wrong fairytale > to newcomer. Yes, it _is_ fair. The opposite is evidently unfair. > DOS doesn't restrict you in any way to > to 16 bit operand size or 16 bit addressing modes > and you are also not bound to real/v86 mode. Then how is it that 99,999999...% of Dos posted examples are 16 Bits .com Files? > For learning assembly programming, there is nearly > no difference between using DOS or Windows: The very first one is that, with DOS, they are learning stuff, that nobody uses since ages. So forth, learning how to program an Application that nobody will even take a look at, is simply demential. > in > DOS you are restricted in the amount of usable memory > (but this really doesn't matter for learning assembly > programming) and there is much less overhead in DOS > than in Windows (executable file format, OS API) which > makes it much easier to start assembly programming in DOS. There are other interrest in Assembly than "learning Assembly". For example, writing Applications in Assembly. Assembly is not a Language for learning Assembly. All Languages are for doing _something_. > As an example a program which calculates the md5 hash > for stdin. There is no way to tell if this is a Win32 > or a DOS program. It can be assembled for both, all > you have to do is to insert the proper getc, putc and > exit functions. If so, why doing it for a dead OS? You are just giving the proof that there is no reason for spoiling time with DOS, with your own example! How can you fail to see this? ... Stucks me... :( Betov. < http://rosasm.org/ >
From: Annie on 12 Mar 2005 07:47 <html> <pre> On 2005-03-12 BethStone21(a)hotmail.NOSPICEDHAM.com said: > [ ... snip ... ] > > My "best guess" as to why Intel chose this scheme - which is a > bit "brain-dead" in many regards - is to remember one other > small but significant fact: CPUs typically _weren't_ in "CPU > families" at this time...the 8086 is _similar_ to their previous > 4004 chip, for example... _____ [*sigh*] Beth, you're talking ((( `\ out of your lower orifice again. _ _`\ ) (^ ) ) Intel "chose this scheme" so that ~-( ) its 16-bit CPU would be reason- _'((,,,))) ably comfortable and familiar ,-' \_/ `\ architecturally to the user ( , | base of its prevalent and highly `-.-'`-.-'/|_| successful line (family?) of 8-bit \ / | | chips...and thereby facilitate a =()=: / ,' aa relatively easy port of existing 8-bit software to the 16-bit CPU. BTW, the 4004 was a 4-bit chip (duh!). The succession was: 8008 -> 8080 -> 8085 -> 8086 -> 8088 -> 80186 -> etc. |_______|_______| |_______|_______| | | 8-bit 16-bit Do you just make this stuff up on the spur of the moment, or what? Hehe! </pre> </html>
From: Tom on 12 Mar 2005 09:17 Ladies and gentlemen, Thank you ALL very much for your most instructive replies. I will study them all thoroughly. My question, however, remains: Why absolute address = segment *16 + offset, and not just absolute address = segment + offset. So, why the division (first) and multiplication (back again)? I understand I can take it the way it comes, still, there needs to be a sensible because to this why. Thank you very much. Tom
From: 'o//'annabee on 12 Mar 2005 09:33 Pý 12 Mar 2005 06:17:16 -0800, skrev Tom <tmyslovsky(a)yahoo.com>: > > Ladies and gentlemen, > > Thank you ALL very much for your most instructive replies. I will study > them all thoroughly. > > My question, however, remains: > > Why absolute address = segment *16 + offset, and not just > absolute address = segment + offset. > > So, why the division (first) and multiplication (back again)? Theres a very good explaination of this on Alex's homepage, here : http://alexfru.narod.ru/os/c16/c16.html#SegOfsPair > I understand I can take it the way it comes, still, there needs to be a > sensible because to this why. > > Thank you very much. > > Tom > -- http://TheWannabee.org
From: Herbert Kleebauer on 12 Mar 2005 11:03
Betov wrote: > Herbert Kleebauer <klee(a)unibwm.de> ýcrivait news:4232D11F.A23FD459 > > It is not fair to tell this old but wrong fairytale > > to newcomer. > > Yes, it _is_ fair. The opposite is evidently unfair. Then it is also fair to let you in the wrong believe, that there is an "assembly rebirth"? > > DOS doesn't restrict you in any way to > > to 16 bit operand size or 16 bit addressing modes > > and you are also not bound to real/v86 mode. > > Then how is it that 99,999999...% of Dos posted examples > are 16 Bits .com Files? You still didn't get it. The posted code can be assembled as 16 bit com program or as 32 bit Windows program without any change in the source code. CPU instructions are far below the OS level, the CPU executes the given instructions and doesn't care about the OS. Assembly programming is pretty independent of the OS or CPU mode (real/v86/protected mode). > > For learning assembly programming, there is nearly > > no difference between using DOS or Windows: > > The very first one is that, with DOS, they are learning > stuff, that nobody uses since ages. So forth, learning > how to program an Application that nobody will even take > a look at, is simply demential. They learn how to write a sequence of CPU instructions to solve a given problem. This instructions are executed by the CPU and not by the OS. > > in > > DOS you are restricted in the amount of usable memory > > (but this really doesn't matter for learning assembly > > programming) and there is much less overhead in DOS > > than in Windows (executable file format, OS API) which > > makes it much easier to start assembly programming in DOS. > > There are other interrest in Assembly than "learning Assembly". > For example, writing Applications in Assembly. Before you can write applications in assembler you have to learn programming in assembler. And there is no easier way than to do this in DOS (or a "DOS box" in Windows). And before you can write applications for Windows, you have to learn the Windows API. And there is no need to learn the API using assembler you can do this also using C with all the examples available. > Assembly is not a Language for learning Assembly. All Languages > are for doing _something_. What language is then the proper language for learning assembler? > > As an example a program which calculates the md5 hash > > for stdin. There is no way to tell if this is a Win32 > > or a DOS program. It can be assembled for both, all > > you have to do is to insert the proper getc, putc and > > exit functions. > > If so, why doing it for a dead OS? Why was it done for a dead OS? It was done as a sequence of CPU instructions. And this sequence can be executed within a DOS com program or a Win32 program or a Linux executable. But there is much less overhead if you execute the CPU instructions within a DOS com program. I post as separate follow up's the complete source code for the DOS com program and the Win32 program. The main code is completely identical, different is only the implementation of getc, putc and exit and the executable file format. As you see, the Win32 source is three times as big as the DOS source. Now you will tell me, that, if I would use your assembler, I wouldn't have all this overhead for the file format. But that's not learning assembly programming. Learning assembly programming means to hide nothing. Once you have understood how it works, then there is no need to do it by hand anymore, the assembler can do it for you. But you have to know what is hidden by the assembler, so you can override the default behavior of the assembler if that isn't appropriate in a special case. The same is true for assembly programming itself. Once you know assembly programming, there seldom is a need to use it. As you let your assembler hide the exe file format, so let a HLL hide the CPU instruction level. Only if the hidden CPU instructions aren't appropriate in a special case, overwrite them with inline assembly code. And don't use some HLL preparser in an assembler to hide the CPU level but an optimizing real HLL. |