From: "Tony Ingenoso" 

What I'm talking about is understanding x86 architecture.  When you
understand the chip, its quirkiness isn't always a liability to be scoffed
at.

There's usually several ways to do things, some faster or smaller than others.
Understanding the situation a piece of code will run under whould dictate your
choice..as well as target CPU.  An embedded 386sx will want to favor space
over "nominal" speed almost all the time. For example:

MOV EAX,1   (this is a 5 byte instruction in flatland, 3 mem cycles just to
fetch)

on a 386sx type CPU it can be replaced with (if you don't care about flags):

XOR EAX,EAX  (2 bytes)
INC EAX  (1 byte)

That 2 instruction sequence that only takes 3 bytes uses 2 mem cycles on an
sx to fetch.  On the 386sx, the two instruction sequence benchmarks ~30%
faster and is 2 bytes smaller.  DX's run it a bit slower than the more
obvious MOV
though.  386's and 386SX's are still popular in the embedded market so these sort
of distinctions are still meaningful.

That particular piece of code I linked to is pre-kernel loading running in real mode
when kernel command line options are being passed.  i.e. it only runs once per boot.
Speed is meaningless there - it should be as compact as possible.  The smaller all
that sort of crap is, the more opportunity there is to include drivers on a
single disk
install/rescue floppy without blowing out its capacity forcing the user to
do a "floppy
shuffle" to find the drivers they need.

"Hrvoje Mesing"  wrote in
message news:42765dcd{at}w3.nls.net...
>
> You are on *crack*! :p
>
> Wtf, I hardly understand what are You taking about there ..
> Hell, in asm I only knew how to echo out the Hello and Kern hacking is
> really too dificult.
> + device driver coding ?! Hell no.
>
> But! .. anyone can name a book for Newbie Debugging ? > still, something
> that like windows more.
>
> thank You,

--- BBBS/NT v4.01 Flag-5