From: NoDot on
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
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
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

"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
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

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Prev: stricmp
Next: Killing Explorer