On Tuesday, June 29, 2021 at 1:10:36 PM UTC-5, robf...@gmail.com wrote:
> I do not seem to be able to follow the example.
<
If you did not snip so much we could follow your train of thought.
<
>Why cannot other instructions decode and execute during that time?
<
Those other instruction following the EXC are dependent on whatever the EXC instruction does.
And since you have not seen the bit pattern of the instruction to be EXCed you don't know what
those dependencies might be !!
<
>It is just a load operation taking place to load the instruction. Things would proceed as per a normal load. It may be many more cycles / instructions before the instruction EXEC is executed. Once EXEC is decoded / issued it is just a matter of waiting for register values.
<
No, it is also a mater of successive instructions not having "done the wrong thing" because
of assumptions you made following EXC.
<
> >What is the semantic if you wanted to EXEC a register and the instruction needed 96-bits,
> >128-bits, or 160-bits ??
> Instructions are limited to 36-bits in this case. I think using more registers to contain instruction modifiers will work.
>
> I think it is execute of the one particular instruction that must stall, not decode. On my machine other instructions can be decoded or execute.
<
What if those instructions are dependent on the (not yet seen) instruction which will be EXCed ?
<
>This is relied on to hide the decode time in many cases.
> If the registers are valid before the EXEC is processed, then it will be fast. Hmm, it just occurred to me that I put a four-cycle lockout in the execute scheduler to prevent it selecting the same queue slot until there was time to mark the instruction as out. So, EXEC would take five or more cycles to execute. Of course, it is mostly hidden time.
<
Our point is that it cannot (CAN NOT) be hidden due to various dependencies you cannot
resolve until the bit pattern of the instruction to be EXCed is seen.
>
> It is very few LOC to implement EXEC. The biggest piece is probably the mux on the IR. I am waiting to see how much it impacts design size, but synth keeps crashing on me.
> I think all that needs to be done is:
> if (robo.exec) begin
> rob[robo.rid].ir <= robo.res.val[35:0]; // comes from register arg A
> rob[robo.rid].dec <= FALSE;
> rob[robo.rid].out <= FALSE;
> rob[robo.rid].cmt <= FALSE;
> rob[robo.rid].cmt2 <= FALSE;
> rob[robo.rid].vcmt <= FALSE;
> end

> The predictor MAY supply such a value, which MAY be correct.
> However the design must deal with the possibility that the predictor
> responds with "no hit", or "hit" but provides the wrong value.

AFAIK all BTBs always return a value. It may be complete garbage
(e.g. when you turn on the power), but it always predicts something.
IOW instead of stalling the pipeline they'll get a mispredict later on.

Stefan

> Our point is that it cannot (CAN NOT) be hidden due to various
> dependencies you cannot resolve until the bit pattern of the
> instruction to be EXCed is seen.

I think it's not that bad: you'd just have an "exec predictor" alongside
the other branch predictors, which returns the instruction likely to be
executed by a given EXEC instruction.

Still, the benefit of such an instruction sounds quite dubious.

[ Note: the EXEC instruction in Forth has the same name but is a quite
different beast. Since it takes an instruction *name* as argument,
which corresponds conceptually to an address rather than an actual
machine-language instruction. It naturally maps to "JAL reg" rather
than an EXEC instruction when you generate machine-language code. ]

Stefan

On Tuesday, June 29, 2021 at 4:56:38 PM UTC-5, Stefan Monnier wrote:
> > Our point is that it cannot (CAN NOT) be hidden due to various
> > dependencies you cannot resolve until the bit pattern of the
> > instruction to be EXCed is seen.
<
> I think it's not that bad: you'd just have an "exec predictor" alongside
> the other branch predictors, which returns the instruction likely to be
> executed by a given EXEC instruction.
<
You missed my point:: code is execution and modifying various registers;
now along comes an EXC instruction that will modify registers--but until
the bit pattern shows up you can't decide which subsequent instructions
can run and which must wait (until the data, memory, flow) dependency
the EXC instruction may create by executing.
<
>
> Still, the benefit of such an instruction sounds quite dubious.
>
> [ Note: the EXEC instruction in Forth has the same name but is a quite
> different beast. Since it takes an instruction *name* as argument,
> which corresponds conceptually to an address rather than an actual
> machine-language instruction. It naturally maps to "JAL reg" rather
> than an EXEC instruction when you generate machine-language code. ]
>
>
> Stefan

>Our point is that it cannot (CAN NOT) be hidden due to various dependencies you cannot
>resolve until the bit pattern of the instruction to be EXCed is seen.

Thank-you for clarifying that. My skulls a little dense some days. Of course following instruction cannot work until the dependencies are resolved. What if the target register were specified in the instruction? The same target register as used in the instruction in the register. One could stipulate that the EXEC instruction must always use a particular register. In order for EXEC to be useful the registers would need to be known in advance. Registers feeding the EXEC need to be known too. One must know and plan how the EXEC instruction will fit into code.
I tried synth and it increased the size of the design by about 3% which is more than I expected.

On Tuesday, June 29, 2021 at 8:05:07 PM UTC-5, robf...@gmail.com wrote:
> >Our point is that it cannot (CAN NOT) be hidden due to various dependencies you cannot
> >resolve until the bit pattern of the instruction to be EXCed is seen.
> Thank-you for clarifying that.
<
It seems to be a job that falls upon my shoulders.......
<
>My skulls a little dense some days. Of course following instruction cannot work until the dependencies are resolved. What if the target register were specified in the instruction?
<
This helps, but subsequent instructions still cannot damage any of the source registers, either.
And if EXC is EXCing a LD instruction no subsequent ST can modify memory to the (as yet unknown) cache line.
<
>The same target register as used in the instruction in the register. One could stipulate that the EXEC instruction must always use a particular register. In order for EXEC to be useful the registers would need to be known in advance. Registers feeding the EXEC need to be known too.
<
What might be workable is to have the EXC instruction specify all of the operand and result
registers and the EXCed instruction only supplies the OpCode. Other than that and you can't
trace the dependencies 'cause you haven't seen the bit patterns in the instruction to be EXCed.
<
> One must know and plan how the EXEC instruction will fit into code.
> I tried synth and it increased the size of the design by about 3% which is more than I expected.

>> I think it's not that bad: you'd just have an "exec predictor" alongside
>> the other branch predictors, which returns the instruction likely to be
>> executed by a given EXEC instruction.
> You missed my point:: code is execution and modifying various registers;
> now along comes an EXC instruction that will modify registers--but until

Hmm... I don't see the problem: the "exec predictor" will predict the
actual instruction that will be executed. It'd be a prediction
structure much like a BTB, except that it returns an instruction rather
than an address: you index it with (a hash of) the address of the EXEC
instruction and it returns the bits of the instruction that was last
EXEC'd at that (hash of) address. So you take that predicted
instruction and stuff it into your instruction sequence.

When you finally do execute the EXEC you just check that the instruction
is equal to the predicted one and if not you do the misprediction rollback.

A lot of work for a not very useful feature, but if you're really intent
on providing it efficiently it seems not terribly hard. The harder part
might be the "stuff it into your instruction sequence".

Stefan

Stefan Monnier wrote:
>> The predictor MAY supply such a value, which MAY be correct.
>> However the design must deal with the possibility that the predictor
>> responds with "no hit", or "hit" but provides the wrong value.
>
> AFAIK all BTBs always return a value. It may be complete garbage
> (e.g. when you turn on the power), but it always predicts something.
> IOW instead of stalling the pipeline they'll get a mispredict later on.
>
>
> Stefan

The ones I have seen had Valid flags on their entries.
But since aliasing can occur one can add tags to try to limit it,
and a tag compare can generate a miss.

The pipeline can stall for other reasons than mispredict.
e.g. ROB fills up, Rename runs out of physical registers.
There are two kinds of stage stall signals: generated and propagated.
Each stage must propagate stall signals from later ones to earlier.
Some also can internally generate stalls. So what we are discussing is
whether Decode also has a FF and a little logic that generates a stall.

There are a bunch of scenarios where Fetch-Parse make a decision
about which path to follow, that Decode can detect as erroneous.
If this happens, Fetch could go off on a wild goose chase so Decode
should halt it until the situation resolves.

In my design, Parse puts the instruction bytes into the parse buffer,
and it includes any prediction information it used to decide the
next IP address. Decode cross-checks the prediction path followed
against the decoded instruction, and if they don't match
- purges parse buffers
- if possible Decode redirects Fetch to the correct path
- if correction not possible, Decode stalls Fetch until
Branch Control Unit (in back end) can resolve.

E.g.1: Fetch looks up an IP in BTB and gets a miss so continues sequentially.
Parse includes this prediction in the instruction buffer.
Decode detects an unconditional branch that was not in the BTB.
Decode calculates the correct branch destination,
purges the parse buffers, and redirects fetch to the correct path.
Penalty: 1 clock * issue width instructions.

E.g.2: Fetch looks up IP in BTB, gets hit and instruction type is RET.
So it consults the Return Stack Predictor and return stack underflows
due to prior overflow and wrap around, so no return address.
Parse puts instruction in parse buffer and stalls Fetch
to prevent it running off into the wild.

E.g.3: Fetch looks up IP in BTB, gets hit and instruction type is RET.
It consults the Return Stack Predictor and gets a return address.
Parse puts instruction in parse buffer with prediction.
Decode checks the instruction and sees it is not a RET
(so this was a false hit due to BTB entry aliasing).
Decode purges the parse buffers, and redirects Fetch to the correct path.
(There is probably some fix ups to the Return Stack Predictor too
if Fetch adjusted its copy of that stack.)
Penalty: 1 clock * issue width instructions.

On Monday, June 28, 2021 at 8:21:44 AM UTC-6, Stefan Monnier wrote:

> As a compiler/proglang guy, the one thing that stumps me instead here is "why?".
> Why would you want, or when/where would you need something like an
> "exec" opcode? It seems to me like a "solution" in search of a problem.

Well, the "execute" instruction used to be provided on very old architectures.

They were usually advanced enough to include an index register, though, so that
wasn't the problem they solved.

Since they were old architectures, they didn't have the problem that memory
access was enormously slower than arithmetic.

One possible use for an execute instruction:

The architecture has "pseudo-ops". These have the form of a memory-reference
instruction (the machine is an accumulator to memory machine, so all the
arithmetic instructions have that form). Only the opcode is used.

So if you were, say, implementing floating-point in software, you could use
a pseudo-op as an "add floating" instruction in this way:

Have the "add floating" subroutine include two exec instructions, both of which
target the pseudo-op that invoked the subroutine. The floating-point number to be
added is the *operand* of the pseudo-op. The exec instructions modify the pseudo-op
to make it a load instruction, and one of them adds 1 to the address as well.

So this way you don't have to chop the instruction up into bits and write a subroutine
to decode it; you're using the computer's own built-in ability to decode instructions to
do that work for you.

John Savard

On Tuesday, June 29, 2021 at 11:12:57 PM UTC-6, Quadibloc wrote:
> On Monday, June 28, 2021 at 8:21:44 AM UTC-6, Stefan Monnier wrote:
>
> > As a compiler/proglang guy, the one thing that stumps me instead here is "why?".
> > Why would you want, or when/where would you need something like an
> > "exec" opcode? It seems to me like a "solution" in search of a problem.
>
> Well, the "execute" instruction used to be provided on very old architectures.
>
> They were usually advanced enough to include an index register, though, so that
> wasn't the problem they solved.
>
> Since they were old architectures, they didn't have the problem that memory
> access was enormously slower than arithmetic.
>
> One possible use for an execute instruction:
>
> The architecture has "pseudo-ops". These have the form of a memory-reference
> instruction (the machine is an accumulator to memory machine, so all the
> arithmetic instructions have that form). Only the opcode is used.
>
> So if you were, say, implementing floating-point in software, you could use
> a pseudo-op as an "add floating" instruction in this way:
>
> Have the "add floating" subroutine include two exec instructions, both of which
> target the pseudo-op that invoked the subroutine. The floating-point number to be
> added is the *operand* of the pseudo-op. The exec instructions modify the pseudo-op
> to make it a load instruction, and one of them adds 1 to the address as well.
>
> So this way you don't have to chop the instruction up into bits and write a subroutine
> to decode it; you're using the computer's own built-in ability to decode instructions to
> do that work for you.

So this explains why the Execute instruction was not only very useful, but even almost
necessary, on computers like the SDS 930. (Having been in the same room as one at
times, I can attest that this is a computer that actually existed.)

Out of curiosity, I checked the Principles of Operation of the IBM System/360 to see
if _it_ had an Execute instruction. It did. But it had limitations which meant that it
could *not* be used the way the execute instruction on the SDS 930 could be used.

Only bits 8 through 15 of the executed instruction could be modified. This was done
through means of an OR operation. So the displacement in a memory-reference
instruction couldn't be changed, nor could the opcode be changed. And, indeed, I
doubt that the System/360's Execute instruction _was_ ever used much.

But what was it _intended_ to be used for? The things it _could_ modify were the source
and destination registers of register-to-register instructions, or the destination and index
registers of memory-to-register operations.

So the thinking behind it was this: the System/360 had sixteen general registers. It was
possible to write programs that looped to do something with successive locations in
memory. It might be desired to loop through registers too, given that there are so many
general registers provided. (To do so meant a memory access to get the executed
instruction, but that was not so much of a concern in those days.)

John Savard

On Wednesday, June 30, 2021 at 2:26:30 AM UTC-6, Quadibloc wrote:

> Only bits 8 through 15 of the executed instruction could be modified. This was done
> through means of an OR operation. So the displacement in a memory-reference
> instruction couldn't be changed, nor could the opcode be changed.

On further reflection, that did not prevent the System/360's Execute instruction from
being used to assist in handling pseudo-instructions in a program. All that would have
been necessary would be to use it in reverse: that is, instead of executing the
pseudo-instruction itself, take the destination and index fields from it to modify an
instruction within the emulator that gets executed instead.

John Savard

Quadibloc [2021-06-29 22:12:55] wrote:
> On Monday, June 28, 2021 at 8:21:44 AM UTC-6, Stefan Monnier wrote:
>> As a compiler/proglang guy, the one thing that stumps me instead here is "why?".
>> Why would you want, or when/where would you need something like an
>> "exec" opcode? It seems to me like a "solution" in search of a problem.
> Well, the "execute" instruction used to be provided on very old architectures.
[...]
> So this way you don't have to chop the instruction up into bits and write a subroutine
> to decode it; you're using the computer's own built-in ability to decode instructions to
> do that work for you.

Thanks, that's a nice example. Clearly on modern CPUs, this kind of
twiddling is not very popular any more, but I can imagine it being still
done on minimalist embedded CPUs (tho even the cheapest of them seem to
be quickly moving to "mature" ISAs like ARM).

Stefan

On Wednesday, June 30, 2021 at 8:14:08 AM UTC-6, Stefan Monnier wrote:

> Thanks, that's a nice example. Clearly on modern CPUs, this kind of
> twiddling is not very popular any more, but I can imagine it being still
> done on minimalist embedded CPUs (tho even the cheapest of them seem to
> be quickly moving to "mature" ISAs like ARM).

Whenever a computer uses "millicode" - subroutines in a version of its own ISA - to
implement some instructions, some form of Execute instruction makes sense. As
that was true even on recent z Series mainframes from IBM, it's at least possible this
is a necessary thing to have on desktop-class processors.

After all, it's not enough for an ISA to just be Turing-complete. It's desired to be
efficient for the kind of tasks it will do. So another question that occurs to me is:
is it _ever_ going to be important to have the ability to address registers indirectly?
I suppose if one were implementing the load and store multiple instructions in
software or millicode.

It is obvious that a compiler wouldn't generate Execute instructions as a... consequence
of a combination of multiple operations within code to be compiled. That a single
operation within code might, however, be implemented by something including an
Execute instruction is a different issue.

So if a computer were "missing something" for a given language, that would be a
good case. Of course, though, a well-designed computer *won't* be missing something
needed to compile C or Fortran or COBOL, would it?

But what about LISP or SNOBOL?

I tended not to think that an Execute instruction is very relevant these days, but now that
I think of it, because of this discussion, it is possible that it does give a computer needed
flexibility - and in a cheap way. Or is that flexibility that's needed more by viruses than by
legitimate programs, making it a very good idea to drop the Execute instruction? Now I'm
wondering about this - in addition to thinking about it, though, I'll see if any research is out
there.

John Savard

On Wednesday, June 30, 2021 at 3:26:30 AM UTC-5, Quadibloc wrote:
> On Tuesday, June 29, 2021 at 11:12:57 PM UTC-6, Quadibloc wrote:
> > On Monday, June 28, 2021 at 8:21:44 AM UTC-6, Stefan Monnier wrote:
> >
> > > As a compiler/proglang guy, the one thing that stumps me instead here is "why?".
> > > Why would you want, or when/where would you need something like an
> > > "exec" opcode? It seems to me like a "solution" in search of a problem.
> >
> > Well, the "execute" instruction used to be provided on very old architectures.
> >
> > They were usually advanced enough to include an index register, though, so that
> > wasn't the problem they solved.
> >
> > Since they were old architectures, they didn't have the problem that memory
> > access was enormously slower than arithmetic.
> >
> > One possible use for an execute instruction:
> >
> > The architecture has "pseudo-ops". These have the form of a memory-reference
> > instruction (the machine is an accumulator to memory machine, so all the
> > arithmetic instructions have that form). Only the opcode is used.
> >
> > So if you were, say, implementing floating-point in software, you could use
> > a pseudo-op as an "add floating" instruction in this way:
> >
> > Have the "add floating" subroutine include two exec instructions, both of which
> > target the pseudo-op that invoked the subroutine. The floating-point number to be
> > added is the *operand* of the pseudo-op. The exec instructions modify the pseudo-op
> > to make it a load instruction, and one of them adds 1 to the address as well.
> >
> > So this way you don't have to chop the instruction up into bits and write a subroutine
> > to decode it; you're using the computer's own built-in ability to decode instructions to
> > do that work for you.
> So this explains why the Execute instruction was not only very useful, but even almost
> necessary, on computers like the SDS 930. (Having been in the same room as one at
> times, I can attest that this is a computer that actually existed.)
>
> Out of curiosity, I checked the Principles of Operation of the IBM System/360 to see
> if _it_ had an Execute instruction. It did. But it had limitations which meant that it
> could *not* be used the way the execute instruction on the SDS 930 could be used.
>
> Only bits 8 through 15 of the executed instruction could be modified. This was done
> through means of an OR operation. So the displacement in a memory-reference
> instruction couldn't be changed, nor could the opcode be changed. And, indeed, I
> doubt that the System/360's Execute instruction _was_ ever used much.
>
> But what was it _intended_ to be used for?
<
IBM 360 had the channel number as part of the I/O instructions.
But channel number was not known until execution begins.
Hense the EXC instruction.
But in this case the proper solution would have been to make a register contain
the channel identifier and dispense with the EXC.
<
> The things it _could_ modify were the source
> and destination registers of register-to-register instructions, or the destination and index
> registers of memory-to-register operations.
>
> So the thinking behind it was this: the System/360 had sixteen general registers. It was
> possible to write programs that looped to do something with successive locations in
> memory. It might be desired to loop through registers too, given that there are so many
> general registers provided. (To do so meant a memory access to get the executed
> instruction, but that was not so much of a concern in those days.)
>
> John Savard

On Wednesday, June 30, 2021 at 9:47:21 AM UTC-5, Quadibloc wrote:
> On Wednesday, June 30, 2021 at 8:14:08 AM UTC-6, Stefan Monnier wrote:
>
> > Thanks, that's a nice example. Clearly on modern CPUs, this kind of
> > twiddling is not very popular any more, but I can imagine it being still
> > done on minimalist embedded CPUs (tho even the cheapest of them seem to
> > be quickly moving to "mature" ISAs like ARM).
> Whenever a computer uses "millicode" - subroutines in a version of its own ISA - to
> implement some instructions, some form of Execute instruction makes sense. As
> that was true even on recent z Series mainframes from IBM, it's at least possible this
> is a necessary thing to have on desktop-class processors.
>
> After all, it's not enough for an ISA to just be Turing-complete. It's desired to be
> efficient for the kind of tasks it will do. So another question that occurs to me is:
> is it _ever_ going to be important to have the ability to address registers indirectly?
<
This goes into the YECH category. You are making DECODE dependent on the forwarding
stage that occurs after DECODE.
<
> I suppose if one were implementing the load and store multiple instructions in
> software or millicode.
>
> It is obvious that a compiler wouldn't generate Execute instructions as a... consequence
> of a combination of multiple operations within code to be compiled. That a single
> operation within code might, however, be implemented by something including an
> Execute instruction is a different issue.
>
> So if a computer were "missing something" for a given language, that would be a
> good case. Of course, though, a well-designed computer *won't* be missing something
> needed to compile C or Fortran or COBOL, would it?
>
> But what about LISP or SNOBOL?
<
They represent 0.0001% of codes running today.
>
> I tended not to think that an Execute instruction is very relevant these days, but now that
> I think of it, because of this discussion, it is possible that it does give a computer needed
> flexibility - and in a cheap way. Or is that flexibility that's needed more by viruses than by
> legitimate programs, making it a very good idea to drop the Execute instruction? Now I'm
> wondering about this - in addition to thinking about it, though, I'll see if any research is out
> there.
>
> John Savard

> Whenever a computer uses "millicode" - subroutines in a version of its
> own ISA - to implement some instructions, some form of Execute
> instruction makes sense. As that was true even on recent z Series
> mainframes from IBM, it's at least possible this is a necessary thing
> to have on desktop-class processors.

There's been various forms of "millicode" in the last 30 years but
AFAICT none of them reached for EXEC, so I doubt this is true.

> After all, it's not enough for an ISA to just be Turing-complete. It's
> desired to be efficient for the kind of tasks it will do. So another
> question that occurs to me is: is it _ever_ going to be important to
> have the ability to address registers indirectly?

I think it's the kind of feature that would cost more than its benefit.
The whole reason why registers are faster is because you can't address
them indirectly.

This said, you actually can address them indirectly. For a 32-register
machine, the indirect access just costs a 32-way dense switch :-)

> But what about LISP or SNOBOL?

I doubt Snobol is taken into account when designing CPUs nowadays, but
I'd definitely expect that Lisp-like runtimes are among the things that
I'd expect a CPU designer to take into account, yes.
Those needs are still very much alive in more "current" languages like
Javascript, PHP, Haskell, ...

> I tended not to think that an Execute instruction is very relevant
> these days, but now that I think of it, because of this discussion, it
> is possible that it does give a computer needed flexibility - and in
> a cheap way.

AFAICT it's only cheap for non-pipelined CPUs.

Stefan

On 6/30/2021 1:26 AM, Quadibloc wrote:

snip

> Out of curiosity, I checked the Principles of Operation of the IBM System/360 to see
> if _it_ had an Execute instruction. It did. But it had limitations which meant that it
> could *not* be used the way the execute instruction on the SDS 930 could be used.
>
> Only bits 8 through 15 of the executed instruction could be modified. This was done
> through means of an OR operation. So the displacement in a memory-reference
> instruction couldn't be changed, nor could the opcode be changed. And, indeed, I
> doubt that the System/360's Execute instruction _was_ ever used much.
>
> But what was it _intended_ to be used for?

See

http://faculty.cs.niu.edu/~byrnes/csci360/notes/360ex.htm

Scroll down for some usage examples.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

According to MitchAlsup <MitchAlsup@aol.com>:
>> But what was it _intended_ to be used for?
><
>IBM 360 had the channel number as part of the I/O instructions.

No, the I/O instructions all had a base+displacement argument for the
I/O address. If you knew the device address you could put it in the
displacement and use a zero base register, otherwise you put the
address in the register. The second byte of the instruction was part
of the opcode and it's hard to imagine a reason to change it on the
fly. (Don't argue, I have an actual paper S/370 POO here.)

EX was often used to make variable length string instructions like MVC
and CLC. If you wanted to handle variable length data, that's how you
did it.

It might have been useful for SI instructions where the second byte was the
immediate operand, e.g., EX a CLI to compare the low byte of a register with
a byte in memory, but I never saw anyone do that.

>> The things it _could_ modify were the source
>> and destination registers of register-to-register instructions, or the destination and index
>> registers of memory-to-register operations.

It could, but I never saw a non-contrived use of that. It was alwys the length code in SS instructions.

>> So the thinking behind it was this: the System/360 had sixteen general registers. It was
>> possible to write programs that looped to do something with successive locations in
>> memory. It might be desired to loop through registers too, given that there are so many
>> general registers provided. (To do so meant a memory access to get the executed
>> instruction, but that was not so much of a concern in those days.)

In theory I suppose, but I never saw anyone do that.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>[ Note: the EXEC instruction in Forth has the same name but is a quite
> different beast. Since it takes an instruction *name* as argument,
> which corresponds conceptually to an address rather than an actual
> machine-language instruction.

The EXECUTE word has a different name, but is very much the same thing
in a threaded-code Forth as an EXEC instruction is in machine (macro-)
code. You cannot just EXECUTE colon definitions (the Forth equivalent
of a function/procedure), but you can also EXECUTE a primitive, the
equivalent of an instruction.

In a classic indirect-threaded implementation, EXECUTE takes the
code-field address as argument, which, on the machine level is an
address, but it is not the address where some threaded code starts, so
that address would not work as argument for the CALL primitive in
Gforth.

> It naturally maps to "JAL reg" rather
> than an EXEC instruction when you generate machine-language code. ]

EXECUTE performs no JAL, CALL or anything like it in a
threaded-code system. Here's EXECUTE in gforth-fast (not quite
classical, but close enough for the discussion here) for Aarch64:

Code execute
555558265C: mov x3, x27 # code field address to execute
5555582660: mov x0, x25 # stack pointer
5555582664: add x25, x25, #8 # stack pointer update
5555582668: ld x1, [x3,#0] # load code address from code field
555558266C: ld x27, [x0,#8] # load new top-of-stack
5555582670: br x1 # branch to code address
end-code

So, no call (the Aarch64 equivalent of JALR) here.

And here's an ordinary primitive

Code 1+
5555582FD8: add x26, x26, #8 # update threaded-code instruction ptr
5555582FDC: add x27, x27, #1 # add 1 to top-of-stack
5555582FE0: ldur x1, [x26,#-8] # load code address of next word
5555582FE4: br x1 # branch to code address
end-code

So if you have a colon definition like

: bar
execute swap ;

It's threaded code (in gforth-fast) looks like this:

simple-see bar
$7FB740D280 execute
$7FB740D288 swap
$7FB740D290 ;s ok

When I invoke BAR with

1 2 ' 1+ bar cr . .
\ output: "1 3"

the execution token of 1+ is $7FB7397AE8; and at that address you find

7FB7397AE8: D8 2F 58 55 55 00 00 00 - ./XUU...

the entry address of 1+. When calling BAR, first a dispatch to the
code of EXECUTE happens. At that point, the threaded-code instruction
pointer is at $7FB740D288 when EXECUTE is started (it always points to
the next word), but this does not play a role while EXECUTE is
running. EXECUTE itself loads the code address of 1+ ($5555582FD8)
and jumps there. This executes 1+, and 1+ performs a regular dispatch
of the next primitive (SWAP): it increments the instruction pointer to
point to $7FB740D290, loads the code address of SWAP from the old
instruction pointer $7FB740D288, and jumps there. So, as you can see,
control passes from EXECUTE through 1+ to SWAP without any call (JAL)
involved, just like the EXEC instruction does not involve a call.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Wednesday, June 30, 2021 at 9:56:30 AM UTC-6, Stephen Fuld wrote:

> See
>
> http://faculty.cs.niu.edu/~byrnes/csci360/notes/360ex.htm

I see that the description there of what the instruction does is not
quite correct. It says that eight bits of the instruction at the destination
are replaced, when in fact an OR operation is performed - according to
the PoO, which I happened to have been looking at to see if the 360
had one.

In any case, the example is for changing the length of a string, just
as someone noted.

John Savard

Anton Ertl [2021-06-30 17:02:31] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>[ Note: the EXEC instruction in Forth has the same name but is a quite
>> different beast. Since it takes an instruction *name* as argument,
>> which corresponds conceptually to an address rather than an actual
>> machine-language instruction.
> The EXECUTE word has a different name, but is very much the same thing
> in a threaded-code Forth as an EXEC instruction is in machine (macro-)
> code.

That might be true for Forth-style machine language, but "traditional"
machine language uses instructions with internal structure (things like
opcode + register numbers + disp), which makes it quite different from
just a "name of an instruction". To take a simple example, there are
2^32 different instructions in a typical RISC which makes it impractical
(or even impossible on 32bit systems) to implement something like EXEC
via a table lookup or by equating the instruction with a pointer,
whereas those are the two typical ways to handle EXECUTE in Forth.

>> It naturally maps to "JAL reg" rather
>> than an EXEC instruction when you generate machine-language code. ]
>
> EXECUTE performs no JAL, CALL or anything like it in a
> threaded-code system. Here's EXECUTE in gforth-fast (not quite
> classical, but close enough for the discussion here) for Aarch64:
>
> Code execute
> 555558265C: mov x3, x27 # code field address to execute
> 5555582660: mov x0, x25 # stack pointer
> 5555582664: add x25, x25, #8 # stack pointer update
> 5555582668: ld x1, [x3,#0] # load code address from code field
> 555558266C: ld x27, [x0,#8] # load new top-of-stack
> 5555582670: br x1 # branch to code address
> end-code

Indeed you don't need the "and link" part because the call is at the end
so it can be strength-reduced to `br` by tail-call optimization.

Stefan

According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
>> Only bits 8 through 15 of the executed instruction could be modified. This was done
>> through means of an OR operation. So the displacement in a memory-reference
>> instruction couldn't be changed, nor could the opcode be changed. And, indeed, I
>> doubt that the System/360's Execute instruction _was_ ever used much.
>>
>> But what was it _intended_ to be used for?
>
>See
>
>http://faculty.cs.niu.edu/~byrnes/csci360/notes/360ex.htm

See the IBM Principles of Opearation:

http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-7_360PrincOpsDec67.pdf

There's a slightly contrived EX example on pages 128-129.

The 370/XA POO has a more realistic variable length move example on pages A-18 and -19.

http://bitsavers.org/pdf/ibm/370/princOps/SA22-7085-1_370-XA_Principles_of_Operation_Jan87.pdf

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Wednesday, June 30, 2021 at 7:35:21 PM UTC-5, John Levine wrote:
> According to Stephen Fuld <sf...@alumni.cmu.edu.invalid>:
> >> Only bits 8 through 15 of the executed instruction could be modified. This was done
> >> through means of an OR operation. So the displacement in a memory-reference
> >> instruction couldn't be changed, nor could the opcode be changed. And, indeed, I
> >> doubt that the System/360's Execute instruction _was_ ever used much.
> >>
> >> But what was it _intended_ to be used for?
> >
> >See
> >
> >http://faculty.cs.niu.edu/~byrnes/csci360/notes/360ex.htm
> See the IBM Principles of Opearation:
>
> http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-7_360PrincOpsDec67.pdf
>
> There's a slightly contrived EX example on pages 128-129.
>
> The 370/XA POO has a more realistic variable length move example on pages A-18 and -19.
>
> http://bitsavers.org/pdf/ibm/370/princOps/SA22-7085-1_370-XA_Principles_of_Operation_Jan87.pdf
<
In any event, these show that the instruction set was misconceived (at least originally)
and that if properly conceived EXC would not have been necessary.
<

> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

On Wednesday, June 30, 2021 at 7:50:50 PM UTC-6, MitchAlsup wrote:

> In any event, these show that the instruction set was misconceived (at least originally)
> and that if properly conceived EXC would not have been necessary.

Although the most common use of the Execute instruction by ordinary programmers
was to change the length of string operations, I don't think that's what it was intended
for.
I think they did put it in to have a way of making it easier to write routines that serviced
an unimplemented opcode exception by causing the bad instruction to do something
useful, thus extending the instruction set... despite its limitations, which mean that
doing this isn't quite as straightforward as on other architectures.
Also, the fact that the instruction set left some possibilities out doesn't necessarily
mean it was misconcieved. The string instructions were expected to be used for
programs doing stuff like you would do in RPG - or on plugboard tab equipment.
So there would be no need for variable length strings... after all, did anybody use
a work-around to get variable length strings on the 1401?
Because an Execute instruction lets you mess with fields inside an instruction,
it potentially opens up a _vast_ new field of flexibility. Without having to be
naughty and use self-modifying code.
Although even I have my doubts as to whether the _kind_ of flexibility it provides
will really be useful very often.

John Savard

On 2021-06-30, MitchAlsup wrote:
> On Wednesday, June 30, 2021 at 9:47:21 AM UTC-5, Quadibloc wrote:
>> On Wednesday, June 30, 2021 at 8:14:08 AM UTC-6, Stefan Monnier wrote:
>>
>>> Thanks, that's a nice example. Clearly on modern CPUs, this kind of
>>> twiddling is not very popular any more, but I can imagine it being still
>>> done on minimalist embedded CPUs (tho even the cheapest of them seem to
>>> be quickly moving to "mature" ISAs like ARM).
>> Whenever a computer uses "millicode" - subroutines in a version of its own ISA - to
>> implement some instructions, some form of Execute instruction makes sense. As
>> that was true even on recent z Series mainframes from IBM, it's at least possible this
>> is a necessary thing to have on desktop-class processors.
>>
>> After all, it's not enough for an ISA to just be Turing-complete. It's desired to be
>> efficient for the kind of tasks it will do. So another question that occurs to me is:
>> is it _ever_ going to be important to have the ability to address registers indirectly?
> <
> This goes into the YECH category. You are making DECODE dependent on the forwarding
> stage that occurs after DECODE.
> <

That's my feeling exactly. I do not have much experience with CPU
design, but one of the things that I've learned from designing a
pipelined CPU is that different parts of the pipeline have access to
different pieces of information / state, and one clear separation is
instruction information (roughly up to and including DECODE) vs
data information (from REGISTER READ / OPERAND FORWARDING onward).

An EXEC instruction would require you to violate that separation, which
complicates the design. It's one of those things that /can/ be done, but
it's really hard to motivate the extra cost (hardware, testing, security
issues, etc) since the use cases would be very few - and even for the
cases where it could be a useful feature, the performance benefits over
just doing a regular register indirect call are probably only marginal
at best.

/Marcus