Segmentation in real mode
in [ASM]
|
Prev: stricmp
Next: Killing Explorer
From: Beth on 13 Mar 2005 04:30 > Frankie say: > > Tom wrote: > > > 1. Why do segment registers hold segments' paragraph numbers rather > > > than their absolute addresses? > > > > Funny you should ask... (see the thread about ".model" in > > Tasm). It's either: > > > > 1) Because that's the chip the market *demanded* (at *that* > > time). Easy "upgrade path" for 8080 code, and ability to use > > more than 64k without "wasting" much memory. (my theory) Or: > > > > 2) Intel was really stupid. (Beth's theory) Who says these theories are "mutually exclusive"? ;) Also, you are, of course, grossly simplifying my "theory" in order to make it look stupid, so that everyone thinks your "theory" is the right one...of course, so would anyone else use this "tactic" in your shoes too...but let us "acknowledge" the slight "bias" in the reporting here, shall we? :)... Though, please explain this "wasting memory" thing... With "linear addresses" (as I propose) then you'd be using "far" pointers right down to the exact _BYTE_...using "segments" only in the DOS-like way, you're working to the "paragraph boundary", which is every 16 bytes...so, all other things being equal, an 8 byte "waste" on average...admittedly, these "far" pointers on "linear addresses" are a byte or two larger on the "pointer" but that's still 6 bytes better "on average" than the "paragraph boundary" stuff... > > In any case, I think we agree that it wouldn't be a sensible > > way to design a chip *now*. For purposes of *using* it, > > rather than trying to improve on Intel's design, just assume > > "that's the way it is". Yeah; We do agree on that...I'm just thinking it wasn't particularly "sensible" at the time either...and Rene has mentioned he knew someone who worked for Intel at the time and that they _didn't_ find it too "sensible" _at the time_ either...oh, I'm sure there's some strange arcane, voodoo black magic "reason" lurking behind all this, as to why Intel did it...but it wasn't particularly "clever" then and it's certainly not "clever" at all now... Looking up the specs for the 8080, Frank, I notice that, in fact, what "scheme" did the 8080 use for its 16-bit addresses on an 8-bit machine? Ah, that's right...it used two 8-bit registers in a "pair" to create a 16-bit register (namely, "BC", "DE" or "HL")...hence, this is the strangest "upgrade path" from the 8080...surely, "same scheme, upgrade the bitage" (exactly like my proposal) would have made the most sense? Motorola thought so...indeed, _INTEL THEMSELVES_ also thought so later on with the '386 (merely "upgrading" the "offset" registers to 32-bits rather than introducing a whole bunch of "segmented segment registers", which require an address to be multiplied, added, divided by the number you first thought of and such before being used :)... Plus, the 8080 and 8086 are NOT directly "compatible" that a re-write or re-compile is required...so, in fact, making it "similar" for "easy porting" makes sense, yes? Not suddenly re-writing all the rules arbitrarily to invent new "schemes" no-one's ever seen before (nor since)...hence, what I would have thought would have been the _better_ "upgrade path" is just to have _retained_ the same "register pair" scheme for addressing as was on the 8080 but "upgrade the bitage"...an idea Intel couldn't have thought too stupid because that was the _exact approach_ with the '386... It's certainly a strange "conundrum", though...for no seemingly apparently visible reason, Intel went "temporarily insane" on this one idea...perhaps they _thought_ it would make the easier "upgrade path"...they were _WRONG_ to think that, in fact...but, well, they thought it, anyway, and that's "why?"...goodness knows...have Intel written anywhere about their "justifications" for various features? Because, you know, they must sit down and discuss and plan these kinds of things...it would, indeed, be immensely interesting to see what "temporary insanity" lead to this particular decision... [ snip ] > > > Thank you very much for all kind replies. > > > > You're welcome. Thank *you* for the on-topic question! > > Thank YOU. No, no...thank _YOU_...hmmm, I can see this getting silly very quickly, at this rate ;) Beth :)
From: Evenbit on 13 Mar 2005 05:32 Beth wrote: > Annie wrote: > > Beth wrote: > > > [ ... 207 lines -- snipped ... ] > > > > Crikey. Get a life, Beth. Hehe! > > I was merely countering your typically malicious posting, Annie... > > Simply, if you didn't want a response then you shouldn't have made > spuriously inaccurate accusations...because, you see, I fully assure you > that, in such cases, I _WILL_ counter them every single time... > > As I was saying, you're like a moth with a lightbulb or a fly with a > window...you fly towards it - BANG! - you smack your head...then you try it > again...then you try it again...failing to comprehend the "relationship" > that, simply, if you stopped banging your head against the window, then it > wouldn't hurt your head so much... > > If you don't want my responses, then _STOP INVITING THEM_ by posting your > malicious spew requiring the need to counter their "malicious rumours", as > you always do...if you never posted such things, then I'd have absolutely > no need to post "207 lines snipped" responses to them... > > Do you see how this works? It's a very simple thing, really... > > When I post - though I might not always like what I see in response - I do > so fully _welcoming_ discourse and responses ("I may disagree with what you > have to say, but I shall defend, to the death, your right to say it", quote > commonly misattributed to Voltaire but is actually a translation of a line > from "Les Liaisons dangereuses" or "Dangerous Liasons" in English...mind > you, though we may disagree where the quote originates from, I do, indeed, > defend people's right to misattribute it to Voltaire as much as they like > ;)... This is a repeat. I am positive that you posted this exact same response to Annie last year. I guess Annie has a learning disability... ;) Nathan.
From: Evenbit on 13 Mar 2005 05:41 aa> Crikey. Get a life, Beth. EB> Why do Beth's posts bother you so much? Do you feel left out because the ASM-related discussions in here don't draw your interest, so you waste all your posts by typing "Crikey" and counting Beth's lines? Perhaps you should run over there and stand in the corner with Alex the Yepper. ;-) Nathan.
From: Tom on 13 Mar 2005 07:00 Betov wrote: > If you are not that stupid and really want to learn > something about Assembly, you have to take a look at > what the Assembly Programmers are doing and at what > the actual Assemblers are: NASM, RosAsm, FASM, GoAsm. > Each have plenty of valid documentations, Tutorials > and examples, and are doing some serious work, the > serious way. I really do appreciate that. > < http://rosasm.org/ > Surely, all competent asm programmers are acquainted with all the relevant material that is there. I can assure you that your suggestions ARE on my reading list. Thank you very much for writing. Tom
From: Beth on 13 Mar 2005 07:47
Rene wrote: > Tom wrote: > >> I agree. You'll find some people feel that you shouldn't > >> "waste" any time at all learning dos. I'd agree that it > >> isn't worthwhile learning "dos", per se, in any depth, but I > >> agree with you that it's "simpler" to interface with dos > >> than with Windows or Linux. Linux has an "int 80h" interface > >> - similar to the dos "int 21h" interface, but Windows > >> requires calling a "Dynamically Linked Library". Easy enough > >> to *do*, but harder to understand what you're *doing* (IMO). > > > > Yes, thank you. I know, I agree. > > ... and this is all of the sad problem: You agrea > with something that is utterly wrong and completely > absurd. Simply, as DOS is evidently "simpler", at a > technology point of view, you fall easily into the > illusion that it should be easier to program and easier > to understand. This is wrong and the reverse is true. > > There is absolutely nothing different between calling > a DOS interruption, that is a Black Box, doing some > operation, and calling a Win32 Api, that is also a Black > Box, doing some operation. Whatever you _call_ for, be it > an INT or an API, black is black. DOS INTs are, in no > way lesser black than black. Essentially, you're correct... Except that Windows does have its "prohibition" on "direct hardware access"...and writing Windows "device drivers" _ISN'T_ easier than DOS programming...so, with Windows, there can be a "hole" in your assembly education regarding "accessing hardware directly"...oh, granted, with "device drivers" and modern OSes, you don't particularly need to be a great expert on this anymore...but, from an "educational" point-of-view, Windows is, if you like, "prohibiting" a part of a fully rounded assembly language education...there is much to be learnt in general from "direct access"...if assembly language is "talking to the CPU", then "direct access" is learning how to get the CPU to talk to the rest of the system...there's much that can be learnt about "the machine" in this way because, after all, the CPU isn't solely the only component that makes up "the machine"... Nevertheless, what you're saying about 32-bit programming is still correct...simply use _LINUX_ (which allows "direct access" by asking for "permissions" to do so, as "root" user :) in order to do it...also, a UNIX-based education actually has a wider applicability across many OSes (including Windows...where you think Windows got its "stdin" / "stdout" streams stuff from? ;)...than a Windows education, which, in many ways, is often solely applicable to Windows only...though, admittedly, where UNIX may have the "wider applicability", Windows has the "sheer weight of numbers" on its side, as the most used x86 OS (actually, most used OS, full stop)... Linux is often ignored in this context but it's actually arguably the best "compromise"...it has a simple interface (very much like DOS's interface, in fact...you call "INT 80h" rather than "INT 21h", basically :)...it has the simple "32-bit flat mode" addressing, though...it also has "device drivers", proper "multi-tasking" and "multi-user" capabilities (so you can learn about "concurrent programming" and get a taste for the "device driver model")...but, at the same time, as "root", you can still get "permissions" to access I/O devices directly too (such as Frank's fun little "PC speaker" program that plays what I think is supposed to be Mike Oldfield's "Blue Peter" - that whole "yo-ho-ho and a bottle of rum" sea shanty "stylee" - but, well, sounded a little out-of-tune that I couldn't be completely sure...I checked the values for the frequencies, though, Frank, and those seem right for standard "just tuning", so, is it a "timing" problem? Would it be "safe" to hook up the other timer to control the timing properly? Or is Linux using that itself for "task switching" and you'd cause an almighty crash? Ah, the problem of "direct access" under any "multi-tasking system": You can't be sure you're the sole program "accessing" the device at the same time and if two programs ask it to do two completely different things then, well, a complete "roll of the dice" what'll result...probably a crash or something ;)... So, it has all the various "features" to make a very good "learning" environment... The problem? No-one's really written too much about it...a lack of "tutorials" and easily understood "information" about what to do...at least, in "useful form" for the beginner... The _environment_ itself is actually potentially very good for learning because it's very "DOS-like" but _WITHOUT_ the ugly "real-mode addressing"...but, well, UNIX has a "C connection" and, thus, lots of "bias" in that most information ("man pages" and such) are all based on how it's done in C...not a problem for people who already know assembly to "translate" but not particularly useful for "beginners"... Also, most "distros" come with a whole array of useful programming tools "out of the box" too...GCC's always there...which is "handy" for "borrowing" its "LD" linker to "link" up your assembly program, even if you're not using C / C++...and all the great "UNIX tools" like "GREP" (searches for strings in a bunch of files...so, you know, if you're wondering where some "symbol" is defined in a "header file" somewhere, set GREP on the files and let it do all the "looking" for you :)...and "MAKE" (helps maintain multi-file projects by only compiling what needs to be compiled when you make changes, based on the "time stamp" of the files :)...and so forth... Linux's problem is actually "lack of support" (LuxAsm will Hopefully change that, of course :)...but, you know, there's GAS but that's the GCC compiler's "back end" and not particularly "friendly" or well-documented (with odd "AT&T syntax")...then there's NASM but, as great as NASM is, it's a "portable assembler", so, you know, it's not really got anything "specific to Linux" in that sense (but with a good NASM-based Linux tutorial, this would be the "best so far" :)...HLA works on Linux too, of course...but, again, it's not "specific" to Linux...kind of the point with the HLA / AoA is that it concentrates on the _assembly language_ and leaves the "OS specific" parts out of it...and, though Randy has written a "Windows programming with HLA" tutorial book, there is no comparable one for Linux, as far as I know, at the moment (for Linux, there's a "how to write device drivers" tutorial...which is great...but this is not the "beginner" level...in time, Randy will probably close this "gap" in his tutorials but, at the moment, there's nothing "beginner level" which focuses on "Linux programming in HLA" or anything...well, there wasn't last time I looked on Webster for that kind of thing, anyway :)... Windows is more popular so, naturally enough, all the stuff tends to be on Windows...for instance, MASM32 has "Windows headers", RosAsm has "Windows equates" (RosAsm's version of "header files"...serves the same purpose but is "built-in" :) and so forth...and these kinds of files are very handy for beginners, as they define all the various types, constants, API and such that you can access in an "assembly form"...you know, when something is "more popular" then all the "tutorials" and things "gravitate" towards it... Another nice facet of Linux is that the GUI is _separated_ (and, in my opinion, of a superior design)...so, with Windows, you've usually got to "jump in" with "event-driven" programming and windows and things...and that's a whole new subject in itself...but you can comfortably "graduate" in Linux because the distinction between "kernel" and "GUI" is _clear_...but it's all mixed up together in Windows... Linux would be _very good_ as a learning environment, _IF_ only there was comparable "support" for assembly coding on the OS...but, unfortunately, though it's not completely absent, it isn't of the quantity of what you find for DOS or Windows...it's still not really an appropriate "beginner" environment in terms of "header files", "documentation", etc., etc....if you like, there's lots of "unused potential" there, which isn't really bein g "exploited" for learning assembly language as it could be...Hopefully, in time, the situation will become different - as playing around with Linux is becoming more popular - that we can stop talking about "potential" and start pointing out how useful it _actually_ is for "learning assembly"...me, NoDot, Frank and C are currently "working on it" in that regard :)... But, as a little "demonstration": ------------------------------------- ; Example.asm ; ; assemble: ; nasm -f elf -o example.o example.asm ; link: ; ld -s -o example example.o ; run: ; ./example ; ; make entry-point "global" so linker can see it ; global _start ; data section ; section .data String db "Hello, world!", 0Ah ; code section ; section .text _start: ; write string to stdout ; mov eax, 4 ; function (sys_write) mov ebx, 1 ; stdout mov ecx, String ; address of string mov edx, 14 ; number of characters int 80h ; make Linux system call ; exit program ; mov eax, 1 ; function (sys_exit) xor ebx, ebx ; exit code int 80h ; make Linux system call ------------------------------------- All very simple stuff, in fact... Very similar to the DOS "Hello, world!" but that this is true 32-bit programming (no messing around with "segments" or 640KB "limits" ;)...that Linux uses "int 80h" rather than "int 21h" (different functions provided than DOS, obviously, too :)...none of that silly "$" sign stuff to end the strings (you pass it the number of characters as part of the function call, so it doesn't actually need a "terminator" at all...very good practice to not create accidental "buffer overflow" bugs too...Microsoft should pay attention! ;)... Beth :) |