davidsen@steinmetz.ge.com (William E. Davidsen Jr) (07/20/88)
The old GE600 series had two instructions called XEC (execute) and XED
(execute double). What these did was to fetch an operation from the
target location and execute it (or them) while leaving the IC pointing
at the XED instruction. Since the machine was able to apply IC
modification to any operation, jumps relative to the original
instruction were allowed.
Here is how it could be used for a procedure call:
xed proc1 ; call proc1
proc1: even
stc1 stak,di ; push on stack "stak" the IC+1 and
; flags, IC still at XED
jmp *+1 ; 1st instruction in proc1
.
.
ldi stak,i ; reload flags, skip if not needed
jmp stak,idc ; return to caller (I may not have the
; modifier right on this one)
What other machines have this type feature, and do people use it
anymore? It allowed the called program to save the registers modified,
was a one word calling sequence, and didn't destroy ANY registers (the
regular calls set the return in a register). It also saved the flags,
which could be preserved or not.
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -metim@amdcad.AMD.COM (Tim Olson) (07/21/88)
In article <11588@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: | | The old GE600 series had two instructions called XEC (execute) and XED | (execute double). What these did was to fetch an operation from the | target location and execute it (or them) while leaving the IC pointing | at the XED instruction. Since the machine was able to apply IC | modification to any operation, jumps relative to the original | instruction were allowed. Depending upon implementation, you could consider most RISC processors that have delayed branches as having what amounts to the single instruction execute, by putting a jump in the delay slot of another: . . jmp $visit jmp $continue $continue: . . This will cause the following pipeline execution (at least on the 29k): Fetch | <$visit> | <$continue> | <$continue+4> | Decode |jmp $continue | <$visit> | <$continue> | Execute |jmp $visit | jmp $continue | <$visit> | Writeback | | | | This has the effect of executing out-of-line the instruction at the first jump address, then continuing with the stream starting at the second jump address. It may be possible to use this to help debugger breakpoint operation, by moving the instruction at the breakpoint into another location, and replacing it with the breakpoint instruction. When you wish to continue, just execute the replaced instruction out-of-line, and continue with the next. -- -- Tim Olson Advanced Micro Devices (tim@delirun.amd.com)
chris@spock (Chris Ott) (07/21/88)
Bill Davidsen (wedu@ge-crd.arpa) writes: > The old GE600 series had two instructions called XEC (execute) and XED > (execute double). What these did was to fetch an operation from the > target location and execute it (or them) while leaving the IC pointing > at the XED instruction. > > [example deleted] > > What other machines have this type feature, and do people use it > anymore? It allowed the called program to save the registers modified, > was a one word calling sequence, and didn't destroy ANY registers (the > regular calls set the return in a register). It also saved the flags, > which could be preserved or not. > > bill davidsen (wedu@ge-crd.arpa) Yes. There is at least one that I know of. The Data General MV-series machines (and probably the older Eclipse machines, too) have an instruction called XCT, which executes the word in a specified register as an instruction. I don't know much about it, but I don't think it saves the registers or anything like that. It just keeps going, as if the word in the accumulator is the next instruction to be executed. Again, I'm not absolutely certain about this. If anyone knows better, please correct me. There is only one place I've ever seen it used. We have a high- resolution (1280x1024) graphics display controller on our system. To access it, the program needs to use I/O instructions. One part of the I/O instruction cannot be specified at run time (the device number, I think). That is, the device number can only be specified as an immediate operand, not as a value at an address or in an accumulator. Since the GDC can use any of four device numbers, and it is necessary to specify the device number at run time, the instruction has to be set up at run time by loading the bit pattern for the I/O instruction and ORing in the device number. One thing I don't understand is: the machine can be re-microcoded. Why can't they just write a new instruction to allow the user to specify the device code with an accumulator as well? ------------------------------------------------------------------------------- Chris Ott Internet: chris@spock.ame.arizona.edu Computational Fluid UUCP: {hao!noao,allegra,cmcl2}!arizona!amethyst! Mechanics Lab spock!chris University of Arizona -------------------------------------------------------------------------------
Paul_L_Schauble@cup.portal.com (07/22/88)
>> Subroutine linkage via XED instruction.
Well, I can speak for current GE/Honeywell/Bull machines. The sequence using
XED no longer works. It seems that funny things happen if one of the
instruction executed takes a page fault.
This is giving us problems. Having the procedure call that uses no register
is VERY useful.
I don't know of any other machines that have XED. Many to have XEC or
execute remote in one fashion or another: Univac 1100 series, IBM 360/370
series.
Pauldaver@hcx2.SSD.HARRIS.COM (07/22/88)
> What other machines have this type feature, and do people use it anymore?
The Harris H-series has an EXM instruction, whose operand is the address of the
instruction to be executed. (And if the instruction to be executed is a two-
word instruction, the second word must be placed after the EXM instruction!)
Examples of its usage include:
1) Dynamically modifying the count to a shift instruction and EXM'ing the
shift.
2) Selecting which subroutine to call, placing the call instruction in a
memory word, and then EXM'ing the subroutine.
3) Lots more.
Assembly code is neat. :-)haynes@ucscc.UCSC.EDU (99700000) (07/23/88)
A number of machines have had the single execute instruction, including some that had a conditional execute. So far as I know the XED is unique to the GE600 and its successors; in some sense it's an artifact of the machine implementation. That is, the machine was implemented with 72-bit memory, so it always fetched instructions in pairs, so it had a 2-instruction buffer to hold them, so the XED could run out of that buffer. (That was also why there was a repeat double instruction). Or one could say it's a case where there isn't really an architecture because it is intertwined with the implementation. I've always wondered who was (were) the architects on that machine. haynes@ucscc.ucsc.edu haynes@ucscc.bitnet ..ucbvax!ucscc!haynes
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (07/25/88)
In article <7560@cup.portal.com> Paul_L_Schauble@cup.portal.com writes: | This is giving us problems. Having the procedure call that uses no register | is VERY useful. Well, I seem to remember that you could do STC2 STAK,DI ; save IC+2 TRA PROC ; enter routine and then just ret from the routine. This doesn't save the flags, and uses two instructions in the call instead of one, but it should work unless hardware stacks are broken, too. -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs | seismo}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
mark@hubcap.UUCP (Mark Smotherman) (07/26/88)
In article <4235@saturn.ucsc.edu>, haynes@ucscc.UCSC.EDU (99700000) writes: > > A number of machines have had the single execute instruction, > including some that had a conditional execute. So far as I know > the XED is unique to the GE600 and its successors; in some sense > it's an artifact of the machine implementation. That is, the > machine was implemented with 72-bit memory, so it always fetched > instructions in pairs, so it had a 2-instruction buffer to hold > them, so the XED could run out of that buffer. (That was also > why there was a repeat double instruction). Or one could say it's > a case where there isn't really an architecture because it is > intertwined with the implementation. I don't know about the XED instruction on other machines. G.A. Blaauw and F.P. Brooks, *Computer Architecture*, list the Bendix G20 as having a repeat double. Their analysis is that since the Bendix G20 is a single-address machine (as is the GE-600), it needs a repeat double to carry enough addressing information to do something useful (e.g. inner product, table search). They do not indicate if the Bendix machine fetched double words or not. The double-word fetch would also explain why there are pairs of out-of- line instructions executed for each interrupt on the GE-600. (Typically, one of these is equivalent to a call to an interrupt handler.) > > I've always wondered who was (were) the architects on that machine. > I believe Couleur was the principal architect of the GE-600. The first paper was Glaser, Couleur, and Oliver, "System design of a computer for time sharing applications," AFIPS FJCC, 1965 (although the GE-625 was introduced in 1964 and targeted at the 7090 market). It was a very nice machine for its era, with rich addressing modes/ indirection scheme and a relocation register. Interesting features also included tallies for character manipulation and an interrupt inhibit bit in every instruction. In many ways, it is the ultimate IAS-based architecture (i.e. single-address, AC-MQ registers). I enjoyed working with a Honeywell (GE sold out in 1969) 6050 as an undergraduate in the mid-70's. -- Mark Smotherman, Comp. Sci. Dept., Clemson University, Clemson, SC 29634 INTERNET: mark@hubcap.clemson.edu UUCP: gatech!hubcap!mark
aglew@urbsdc.Urbana.Gould.COM (07/26/88)
..> Machines that have EXECUTE and EXECUTE DOUBLE instructions.
Gould Powernodes have EXM (Execute Memory) and EXR (Execute Register)
instructions; EXR has variant EXRR (Execute Register Right), for the
second half of a pair of 16 bit instructions.
I just used an EXM, for an I/O instruction that only had a fixed
address specifier. In general, you try to avoid them, because they
are relatively slow.rwa@auvax.UUCP (Ross Alexander) (07/27/88)
In article <4235@saturn.ucsc.edu>, haynes@ucscc.UCSC.EDU (99700000) writes: > So far as I know > the XED is unique to the GE600 and its successors; in some sense > it's an artifact of the machine implementation. [...] > Or one could say it's > a case where there isn't really an architecture because it is > intertwined with the implementation. > > I've always wondered who was (were) the architects on that machine. XED was quite handy. It let one insert an extra instruction into existing binary code with worrying about branch targets et al., by the simple hack of changing op1 op2 op3 into op1 xed fake op3 [later] fake: op2 extraop and there was no impact on the execution of the modified code, since xed didn't have any linkage overhead or fiddle with the flags. Since there was also an add-one-to-storage instruction (aos), I once wrote a package to take a binary produced by a local B compiler, go through it finding all the basic blocks, and patching in code via the above hack to count executions of basic blocks @ runtime; it helped that the compiler wrote debug-info tables that were easy to find by automated inspection. Maybe this has some relation to the discussion (elsewhere) on the relative merits of self-modifying code :-) ? -- Ross Alexander, Athabasca University, Alberta, Canada eh? [snappy tag-line down for preventative maintenance] alberta!auvax!rwa