Re: interesting use of NEXT SENTENCE vs. CONTINUE
- From: "Chuck Stevens" <charles.stevens@xxxxxxxxxx>
- Date: Tue, 21 Jun 2005 09:13:12 -0700
"Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message news:...
>
> "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote in message
> news:3gsc9uFe0rs5U1@xxxxxxxxxxxxxxxxx
> >
> > "Chuck Stevens" <charles.stevens@xxxxxxxxxx> wrote in message
> > news:d89the$223l$1@xxxxxxxxxxxxxxxxxxxxxxx
> > >
> > > "Pete Dashwood" <dashwood@xxxxxxxxxxxxxx> wrote in message
> > > news:3gpibiFdiejoU1@xxxxxxxxxxxxxxxxx
> > >
> > > > I am asking how a machine language BRANCH instruction (which has a
> > SINGLE
> > > > operand), can be SLOWER than a machine language COMPARE instruction
> that
> > > has
> > > > TWO operands.
To return to this point: There are some assumptions in here that aren't
universal.
In Unisys MCP terminology, a fixed part of a machine instruction isn't an
"operand". Generally speaking, an "operand" on this architecture is a data
word, not a code word, a control word, or a descriptor already on the stack.
An "operand" is also *not* part of the machine instruction itself; fixed
information contained within the instruction is referred to as a
"parameter".
A "static" BRANCH instruction has no operands; it has a *parameter* (within
the instruction, with a fixed value) that includes the word address within
the segment in which the branch occurs (13 bits), and the syllable address
within that word (0-5), to which control is to pass. A code word has a tag
of 3 and cannot be an operand. By convention and by enforcement all
executing instantiations of an object program share a single copy of the
object code segments, both on disk and in memory, and any overwriting of a
code word would destroy that architectural feature.
As stated before, there is no single "compare" instruction with two
arguments. A numeric comparison is done between two operands on the stack,
and is quite rapid. Comparisons of alphanumeric data require two
descriptors on the stack pointing to data in memory and is more costly. In
the former case, the cost of the comparison has to include the cost of
putting the numeric values onto on the stack (with conversion if necessary);
in the most trivial case the value is stored in the proper form and can
simply be retrieved. A compare of two operands -- or of an operand and a
literal -- can be cheap indeed or it can be expensive.
For the cheapest case, the instruction for the retrieval of a value doesn't
have an *operand* either -- the stack cell location to be retrieved is
encoded within the instruction proper. A constant value to be placed on the
stack is encoded in the instruction proper (ZERO, ONE, LT8, LT16 and LT48
are all in the same family; the corresponding instructions are B0, B1, B2
[8-bit literal], B3 [16-bit literal] and B4 [48-bit literal aligned at the
next word in the code stream). EQUL requires two operands -- both already
on the stack
A "dynamic" branch instruction has a single (dynamic) top-of-stack argument.
That argument may be an operand (in which case it's treated as an integer
directing control to pass forward or backward within the current segment),
it may be a Tag-7 word (a Program Control Word), ent number and the word and
syllable address within that segment to which control is to pass, or it may
be an Indirect Reference Word chain that ultimately leads to a PCW.
The case of most interest here is the second, with a PCW argument. A PCW
(ultimately) contains the index into the Actual Segment Descriptor table,
maintained by the operating environment, whose entry corresponds to the
object code file's code segment to which the branch is to proceed; at the
very least, the hardware checks the table entry to find the associated
object code segment already in memory before transferring control to the
word and syllable location specified in the original operand. Whether, and
how long, that code segment remains in memory after any given execution of
code within it is dependent on processes entirely outside the program's
control, largely, the amount of available memory on the system and the
likelihood that that particular code segment (which need not be saved to
disk) will be marked as absent to make space for data.
The point here is that the processing of the variable argument when that
argument, strictly speaking, isn't an *operand*, gets quite expensive.
-Chuck Stevens
.
- Follow-Ups:
- Re: interesting use of NEXT SENTENCE vs. CONTINUE
- From: Pete Dashwood
- Re: interesting use of NEXT SENTENCE vs. CONTINUE
- Prev by Date: PLUG: txt2pdf 8.2
- Next by Date: Re: interesting use of NEXT SENTENCE vs. CONTINUE
- Previous by thread: Re: interesting use of NEXT SENTENCE vs. CONTINUE
- Next by thread: Re: interesting use of NEXT SENTENCE vs. CONTINUE
- Index(es):
Relevant Pages
|
