Re: To RISC or not to RISC
- From: "randyhyde@xxxxxxxxxxxxx" <randyhyde@xxxxxxxxxxxxx>
- Date: 27 Oct 2006 15:52:06 -0700
KJH wrote:
Yes, enter/leave construction... So assembly language has to be the
"flexible partner".
Actually, ENTER is one of those "high-level, VAX-like" instructions
that immediately fell out of favor on the x86 architecture. Not
provding instructions that "close the semantic" gap is one of the
things we've learned from RISC architecture. You can also throw in
instructions like LOOP and most of the string instructions.
But I think it's good to have those instructions
implemented in silicon, by the way.
You might try reading Hennessey and Patterson. They provide a *very
good* argument (which most computer architects agree with) against
"having all these instructions." The problem with the "kitchen sink"
approach is that you have to waste silicon on those instructions long
after the need for them has gone away (ENTER, for example, was created
specifically for Pascal and other block-structured languages, it really
isn't that useful for C-like languages). Having to carry around all
that baggage makes it difficult to boost clock speeds and implement
other, more desireable, features in the CPU.
After all, it's us asm programmers
who win in that situation :) Think about it... high level languages
have no opportunity to choose how much space to allocate when entering
subroutines.
????
Ever use talloc in C?
If C function calls another one, it's allways the same...
???
First of all, "high-level languages" does not equal "C".
Many high-level languages provide dynamic arrays as automatic
variables. So yes, you *can* allocate a different amount of local space
(usually on the stack) on each different procedure call. GCC, if you
will allow non-ansi extensions, can do this, too.
if for example two ints are passed as params, in 32 bit it's 8 bytes on
stack. But in assembly one can allocate casually for example 8
additional bytes more if needed, using enter.
The space allocated by ENTER is usually for local variables (and the
display), not parameters, but okay...
Of course, the amount of storage that ENTER allocates is fixed at
compile time. It is not dynamic as your post suggests. And, of course,
anything you can do with ENTER can be done with a short sequence of
instructions. For example, you can allocate all the local storage you
want using a SUB ESP,const (or even variable) instruction. If you want
to build a display (which most people don't, but something that ENTER
can do), that's easy enough to do, as well. Indeed, the discrete
sequence of instructions that correspond to the semantics of the ENTER
instruction usually execute quite a bit faster than ENTER.
Of course the calling
routine does not know that, but it's possible. Well... what I
particularly like in assembly is that you can define your own calling
conventions, they are not static as in C or generally in HLL.
Parameters passed in registers and all that. Flexibility is the keyword.
Of course, many compiler implementations ( particularly C/C++) provide
the ability to vary the calling convention. Though your point is well
taken, with assembly you can do anything you want.
Cheers,
Randy Hyde
.
- References:
- To RISC or not to RISC
- From: KJH
- Re: To RISC or not to RISC
- From: Betov
- Re: To RISC or not to RISC
- From: KJH
- Re: To RISC or not to RISC
- From: Betov
- Re: To RISC or not to RISC
- From: KJH
- To RISC or not to RISC
- Prev by Date: Re: Time this code, please!
- Next by Date: Re: 12 Misconceptions
- Previous by thread: Re: To RISC or not to RISC
- Next by thread: Re: To RISC or not to RISC
- Index(es):
Relevant Pages
|