In article <············@sytex.com> ····@sytex.com "Scott McLoughlin" writes:
> o At "Border Books", a national chain that tends to carry "good books"
> on CS and other topics, there are currently more books on asm than on
> BASIC, although the popularity of VB seems to be leading a charge. If
> you include books on "cpu architecture" with an emphasis on assembler,
> asm still leads by a wide margin.
I first learned about CPUs and machine code from a book published
in 1980 about microcomputer programmer. It covered Basic and assembly
language. It also had some info about other languages, and asm stuff
wasn't specific to any single processor. I don't know if such general
books are still available, but I wish there were more of them.
> o In just about every DOS BASIC, Pascal, C source I've inherited,
> examined, and written there is some asm in the source.
Yep. Most of the "real code" I've seen is either like that, or
includes calls to library functions specific to a single platform.
> o The famous "SS != DS" .DLL problem, small/medium/large model issue,
> near/far pointer issues in DOS and Windows programming certainly
> aquaint C/Pascal DOS and Windows programmers with CPU related issues.
This can result in some very odd programming habits! I've even
encountered programmers who prefer segments to "flat" address spaces,
on the grounds that it helps overlays. That may be true, but you
have to first assume that overlays are a "good thing", and somehow
(always) inferior to paging.
Could that help explain why Lisp (in whatever form) and Smalltalk
are not too popular with DOS programmers? It could be one reason.
> Anyway, many of the "novices" reared on DOS (a large percentage of
> novice hackers out there, I'd wager) almost certainly have _some_
> aquaintance with asm, sometimes only "cookbook".
Agreed. It's almost impossible not to, if you want to write a
commercial application for DOS. Even if you don't think you need
to, other DOS programmers will expect it, and there may be more
of them than you. That helps shape the market.
> examined the stack, etc. she began RPN'ing like a pro. Before
> absorbing this "machine model" she used to write down all
> intermediate values on paper and reenter them! She's a smart
> cookie too (Harvard/Georgetown).
There's a magic point at which Forth "clicks". Most programemrs
never reach that point, judging by the number of people who fail
to understand the point of RPN. It also helps (later on) to know
how threaded code works, even if your Forth isn't threaded. It's
still the model that is used for the language, even if that Forth
implementation uses native code, like the Novix, for example.
I've no idea how many programmer even bother to take the time to
use Forth as an RPN calculator. When someone dismisses Forth, I
appreciate it when they explain _why_ they felt that way.
--
"Internet? What's that?" -- Simon "CompuServe" Bates
http://cyber.sfgate.com/examiner/people/surfer.html