|
Prev: stricmp
Next: Killing Explorer
From: NoDot on 12 Mar 2005 13:02 Herbert Kleebauer wrote: > Then it is also fair to let you in the wrong believe, > that there is an "assembly rebirth"? It's going on right now. It's just too small to notice at the moment. BTW, the Assembly Rebirth is about assembly taking back its rightful place *beside* HLLs. It will never replace them and probably never will. Trying to is useless. Now, if you don't mind, I have OS Development material (hardware material to be exact) to get back to struggling through. Have a rotten day. :) -- The above was written by NoDot. Visit the Website of NoDot: <www.geocities.com/nodot1989/>
From: NoDot on 12 Mar 2005 13:16 Betov wrote: > ... 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. Programming has three parts: 1. learning how to program (i.e. algorithms, design, etc.) 2. learning the language (C/C++/Pascal/Assembly/etc.) 3. learning the tools (assembler/compiler/library/IDE/etc.) DOS allows one to get the hang of 2, since he probably already knows 1, and then he can move on to learning 3. Things take time. > Betov. -- The above was written by NoDot. Visit the Website of NoDot: <www.geocities.com/nodot1989/>
From: Beth on 12 Mar 2005 13:18 Annie wrote: > Beth wrote: > > [ ... 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. Well, as you know, Annie, "imitation is the sincerest form of flattery"...and I'm such a great fan of yours ;)... > Intel "chose this scheme" so that its 16-bit CPU would be > reasonably comfortable and familiar architecturally to the > user base of its prevalent and highly successful line > (family?) of 8-bit chips...and thereby facilitate a > relatively easy port of existing 8-bit software to the > 16-bit CPU. When did I say otherwise? A "CPU family" is usually regarded as requiring _100%_ "backwards compatibility" with previous chips...not merely "similar"... The "succession" may have been "8008 -> 8080 -> 8085 -> 8086 -> 80186 -> etc."...but the direct "inheritance" was only "8086 -> 80186 -> 80286"... To explain the difference: Charlie is Liz's son...he's direct "family" and will "inherit" the title of Monarch...this is the "Royal family"...and this is, indeed, "succession" to the throne... On the other hand, America's "head of state" - the President - is voted in democratically...Bush senior was NOT Reagan's eldest son NOR was Clinton Bush's eldest son NOR was Bush junior Clinton's eldest son...but they were "in succession" to each other to the title...but there is _NO_ "family" implication to this (though, it's not excluded "by coincidence", such as Bush junior "suceeding" his father, even if not directly because Clinton squeezed himself in-between for a few years :)...there is no "presidential family" (well, other than in a purely _metaphorical_ sense...or referring to something completely different where "families" like the Bushes and Kennedys "coincided" with the Presidential office, which is an altogether different topic :)... Hence, the _succession_ might be "8008 -> 8080 -> 8085 -> 8086 -> 80186" but the "family" in question is _ONLY_ "8086 -> 80186 -> 80286"...these chips are 100% "backwards compatible", which, if you like, is their "genetic inheritance" that makes them "family"... > BTW, the 4004 was a 4-bit chip (duh!). Yes, it was; I only stated, though, that the 4004 was a _previous_ Intel design...simple enough, a straight answer for a straight question: Was the 4004 _before_ the 8086? Yes? Well, that's exactly what I said and all that I said...and if you "miscontrued" any more into it, then that would be _YOUR_ "issue" to resolve, not mine... Indeed, the 4004 _WAS_ completely different in design..._THAT_, dear Annie, was the entire point of mentioning it...the 8008 you list in your "succession" was the "successor" itself of the 4004...but it was NOT part of the same "family"... And the inclusion of the 4004 is _CRUCIAL_ because its exclusion has made you misunderstand the point I was making...for example: > The succession was: > > 8008 -> 8080 -> 8085 -> 8086 -> 8088 -> 80186 -> etc. > |_______|_______| |_______|_______| > | | > 8-bit 16-bit Nope; You've left out the 4004 beforehand...the 8008 was "in succession" to the 4004 too (I mean, even the names point this out, that the number 8008 is 4004 "doubled" to 8-bits ;)...so, really, you meant (split into two, just to try to attempt to avoid "word-wrap" issues :)... 4004 -> 4040 -> 8008 -> 8080 -> 8085 -> 8086 -> 8088 -> 80186 -> ... |________| |_______|_______| |_______|_______| | | | 4-bit 8-bit 16-bit .... -> 80186 -> 80286 -> 80386 -> 80486 -> 80586 -> etc. |________| |________|________| | | 16-bit 32-bit ....and this fully demonstrates _MY_ point that "succession" and "family" are NOT the same thing at all... Plus, this is far too "simplistic" a view, anyway...for example, the "8088" was not "in succession" to the 8086 at all...it was simply an alternative "cheap" version of the 8086 that was 8-bit externally for "compatibility"...and, earlier, the 8085 was just an 8080 that required only a single a 5 volt power supply... You are, thus, being _VERY_ misleading with this "succession" diagram...it needs to be at least two dimensional to get the _relationships_ properly understood: 4004 -> 4040 | 8008 -> 8080 -> 8085[1] | 8086 -> 8088[3] -> 80186 -> 80286 -> 80386 -> 80486 -> etc. 1. The 8085 is, in fact, merely an 8080 with different power supply and internal timer and so forth...so, actually, it's just an "improved 8080" rather than a "next generation" chip from the 8080... 2. The 8088, again, is just an 8086 but with an 8-bit external bus for "compatibility" (and to make it cheaper)...so, again, an "8-bit bus 8086", not an actual "next generation" chip from the 8086... There are three _different_ "families" here, despite "succession"...as I was trying to say, processors were typically NOT made "compatible" in the same way as happened later (for example, the 80386 goes to 32-bits BUT it _DID_ retain complete "backwards compatibility" with the 80286...this had NOT happened previously with Intel, when changing "bitage" and the designs were _different_)...the 4004, 8008 and 8086 were _different designs_... As usual, you _CUT OFF_ my quotation in the middle, in order to try to make it look like I was saying something I wasn't...restoring the sentence that was cut off mid-stream to what I _actually said_: "the 8086 is _similar_ to their previous 4004 chip, for example, but it's not 'fully backwards compatible' with it..." ....which makes perfectly clear that I was considering this in terms of "backwards compatibility"...and "families" retain such 100% "backwards compatibility"... "Succession" simply means that it was the next chip Intel created chronologically...but there is no actual compatibility relationship, so this chronological order doesn't really mean much in terms of programming the darn things... Ignore Intel's numbering system, as it's highly confused...indeed, the likely reason it was called the 8086 rather than something like the 160016 (carrying on the 4004 and 8008 "tradition" :) is most likely nothing more than "sales tactics" because the 8080 had been very successful, so wanted to keep the "recognition" inherent in that number with their customers... There were "similiarities" (after all, same people creating them :) but these were actually _different_ designs and there was not true "backwards compatibility" - binary compatibility - between them...close, but no cigar...while with the x86 range, each "generation" has been completely "backwards compatible" and binary compatible with the previous generation... As to the assertion that this was supposed to aid "porting" from the 8080...possibly...but it's not a wholly convincing case...because, in fact, with the 8080, Intel _EXACTLY_ used the scheme I am suggesting but for the 8-bit case... The 8080 had an accumulator (A) and six secondary registers (B, C, D, E, H and L)...and the 16-bit addresses (64KB) it was capable of dealing with were made by the _EXACT_ "pairing" that I was mentioning...specifically, "BC", "DE" or "HL"...there was no "segmentation", as this was bizarrely introduced for the 8086, as noted...which _SHUNNED_ using the same "pairing" mechanism for addressing as the 8080 had used (but simply extending this to 16-bits, as I was suggesting would have been most sensible)...introducing, instead, the whole screwed up "real mode addressing" scheme... Don't try your "malicious misunderstanding" tricks and cutting off your quotations of what I said to make it seem like I said something _which I didn't_, Annie...we all know your "position"...of trying to hound me out of the group, then trying to discredit everything I said until I was forced to completely ignore you...and now, it seems, you're attempting to be more "subtle" in your approach by presenting a superificial appearance of being "on-topic" but twisting things in tiny ways to try to "undermine" me...you're just like those moths that bang themselves repeatedly over and over against a hot lightbulb, with absolutely no idea when to give up...well, pay attention, moths that do this often exhaust themselves to _death_ doing so...your Liberty, your choice...but surely there are better ways for us to spend our rather short-lived existences on this globe before meeting the Maker, eh? :)... The only "made up" thing here is your _FALSE_ "malicious misunderstanding" of what I've said (which, let us remember, I did clearly label as just my own personal "guess" as to why Intel might have done this)...which, unfortunately, is becoming far more a feature of your posts than of mine...remember your "made up" political spectrum? Your "made up" accusations about Michael Moore's film, not realising I had it on DVD to exactly look up each accusation to find that these "terrible things" suggested were _ALL_ not actually present whatsoever? Stick with your CP/M, Annie...although, remember, run an x86 version, as the 8080 version won't run directly...hmmm, wait a minute...doesn't this suggest you _knew_ that you were talking out of your "lower orifice" in making this "complaint" as a CP/M user? Mind you, what OS you actually run is a good question...you say CP/M one day, then DR-DOS the next...then we hear you say "I don't run any Microsoft software"...but then when someone posts their Windows code, you're found commenting "that's an excellent program"...how would you know if you don't run Windows, as you claim? You think we ain't noticed the inconsistency and contradictions? No, dear Annie...we let it pass because we're not quite so petty-minded, as you strive to be... Beth :)
From: Randall Hyde on 12 Mar 2005 13:25 "Tom" <tmyslovsky(a)yahoo.com> wrote in message news:1110546150.827105.283040(a)g14g2000cwa.googlegroups.com... > Hello, > For some time now I have been learning assembly on my own using > Webster. So far I have managed to build a small paper-and-pencil uP and > read/comprehend most of the material from the 16-bit DOS version of AoA > (I understand DOS is obsolete, but I have found it simpler to start > with, hope to do better in the future). Okay, just be aware that you'll wind up learning a bunch of stuff that you'll have to quickly unlearn once you move on. > > Would you be kind enough as to help me clarify the following points > (regarding real mode programming): > > 1. Why do segment registers hold segments' paragraph numbers rather > than their absolute addresses? Because the segment registers are only 16 bits wide (as were most other registers on the 8086 at the time). Keep in mind, the 8086 only had something like 30,000 transistors (back in 1978, when it first appeared) and register bits consumed quite a few transistors. Paragraph boundaries were a convenient way to extend the addressing space without requiring a whole lot of extra transistors. Of course, the 8086, 8088, 80186, and 80186 were *early* segmentation attempts by Intel, back in the days when transistors where a precious commodity. By the time the 80286 appeared, they'd completely reworked the segmentation model to do something a lot more reasonable (segment values were an index into a lookup table that contained the physical base address and size of a segment). Of course, by then the IBM PC and MS-DOS had become popular and too many programs were written in "real" mode assuming segments fell on paragraph boundaries. As a result, the 80286 protected mode was rarely used except for some software "memory extenders". Even the 80386 protected mode, which was much better (allowing 32-bit offsets into segments) wasn't really accepted until 10 years after the CPU was introduced (which leads me to believe it will be a similar amount of time before the 64-bit x86 extensions see major acceptance). > > 2. In Chapter 6 of AoA (The instruction set, 6.11.1 Simple arithmetic > I) Mr. Hyde gives an example of code in which he declares a procedure > MAIN, which is duly terminated with "Main endp". What does the second > "end Main" expression stand for? Why is this procedure not called? Or > is it? END is a MASM directive that marks the end of the source file. It has nothing to do with the Main procedure. The label after END provides the starting address of the program to the linker. Cheers, Randy Hyde
From: Tom on 12 Mar 2005 14:18
Mr. Hyde wrote: > Okay, just be aware that you'll wind up learning a bunch of stuff that > you'll have to quickly unlearn once you move on. I'll be fine learning more from you, Mr. Hyde. Thank you very much for your kind interest. And thank you for Webster. > > 1. Why do segment registers hold segments' paragraph numbers rather > > than their absolute addresses? > > Because the segment registers are only 16 bits wide (as were most other > registers on the 8086 at the time). Keep in mind, the 8086 only had > something like 30,000 transistors (back in 1978, when it first appeared) > and register bits consumed quite a few transistors. Paragraph boundaries > were a convenient way to extend the addressing space without requiring > a whole lot of extra transistors. I see. Thank you very very much indeed. I spent several days trying to figure that out, but I gave up when I gathered this might be a deep hardware issue. > Of course, the 8086, 8088, 80186, and 80186 were *early* segmentation > attempts by Intel, back in the days when transistors where a precious > commodity. > By the time the 80286 appeared, they'd completely reworked the segmentation > model to do something a lot more reasonable (segment values were an index > into a lookup table that contained the physical base address and size of a > segment). Of course, by then the IBM PC and MS-DOS had become > popular and too many programs were written in "real" mode assuming > segments fell on paragraph boundaries. As a result, the 80286 protected > mode was rarely used except for some software "memory extenders". > Even the 80386 protected mode, which was much better (allowing > 32-bit offsets into segments) wasn't really accepted until 10 years > after the CPU was introduced (which leads me to believe it will be > a similar amount of time before the 64-bit x86 extensions see > major acceptance). I see. Thank you very much. > > 2. In Chapter 6 of AoA (The instruction set, 6.11.1 Simple arithmetic > > I) Mr. Hyde gives an example of code in which he declares a procedure > > MAIN, which is duly terminated with "Main endp". What does the second > > "end Main" expression stand for? Why is this procedure not called? Or > > is it? > > END is a MASM directive that marks the end of the source file. > It has nothing to do with the Main procedure. The label after END > provides the starting address of the program to the linker. I see. Sir, I am most obliged for your kind attention. Thank you. Kindest regards, Tom |