Re: Trivia Question

På 4 Jan 2006 08:14:02 -0800, skrev randyhyde@xxxxxxxxxxxxx <randyhyde@xxxxxxxxxxxxx>:


\\\o///annabee wrote:

Who need that? Someone dealing with writing a compiler! 
 Or a debugger. Or maybe someone really wants to *change* one of the
register values on return (and, therefore, needs to poke a value into
the stack frame where the value for that register is sitting).

Make all the excuses for your ignorance that you like, but, yes,
assembly programmers *should* know about this stuff.

I disagree. This is the kind of stuff that is trivial to enquery once you written
about as much code as I have. You know, the stack may seem strange at first, but the
fact that it grows to lesser adresses, is not really THAT hard to figure out.

Its just that I never needed to know.
There a million things I never needed to know, and even more that I will never need.
But this doesn't make it impossible to wrote FULL PEs in assembly, quite the oposite.

You are actually probably scaring beginners by providing too much info at once.

After all, the
point of assembly language is *not* to write HLL-like code in assembly,

The point of assembly is to program the machine. Its the native language ( -es )
of the machine. To read more into it than that is not fair.

but to take advantage of what the machine has to offer. Now, knowing
the exact sequence of the registers on the stack isn't something that
every programmer ought to have memorized (it's easy enough to look up
when you need it, or you can do something like #include( "x86.hhf" );
and get symbolic equates for these offsets), but a decent assembly
programmer *should* understand why knowing this information may be
useful.

Information are rarely useful until needed. No matter how many manuals,
how many infos you memorized, this will only be a small help at writing programs.
Its not like your memory is the one that moves and inspires you to do programming,

It is your imagination. Then the language becomes a tool to make that thought a
running application. After working with the needed instructions some times, repleatly,
they tend to stick around in your memory.
And when you ever discover something that you cannot formulate, you may take a look at the
instruction set for clues. Then, by and by, you build the needed base to do what you want.

Hopefully, in a few more years, you'll discover why it just
might be important to know the order of the registers pushed on the
stack by pusha/pushad.

If the situation where important, it will be important. Sure. But for more then 2megas
of written sourcecode, between all my apps, this was never needed.
So thats why, it is useless info to throw at a beginner, unless he asks for it.

Cheers,
Randy Hyde


.

Relevant Pages

  • Re: Trivia Question
    ... the stack frame where the value for that register is sitting). ... every programmer ought to have memorized (it's easy enough to look up ... programmer *should* understand why knowing this information may be ...
    (alt.lang.asm)
  • Re: Cost of calling a standard library function
    ... because, though faster from dropping the stack and using EBP, they ... exact same register we copied from, meaning that we're copying a value ... this stuff makes sense and HLL compilers and HLL ... There's no need to optimise ...
    (alt.lang.asm)
  • Re: push pop ebp
    ... > mov ebp, 9000 ... you may use it there; EBP _is_ a general purpose register ... It also nominally the so-called "base pointer" register to be ... "stack frame"...this behaviour, though, is NOT enforced in any ...
    (alt.lang.asm)
  • Re: Forth and OO design?
    ... cell circular data stack ... return stack index register ... No, that is not design. ... language which became the bastardized basis of Javascript. ...
    (comp.lang.forth)
  • Re: ml64, PROC and parameters
    ... _test_nested creates 98h bytes of stack space for the sake of the exercise. ... You should push on the stack only the non-parameter register. ... The first 4 parameters are in registers rcx, rdx, r8, r9. ... mov,rcx ...
    (microsoft.public.development.device.drivers)