🚀 go-pugleaf

In article <11212.664...@mts.rpi.edu> Greg_d...@mts.rpi.edu (Commander Krugannal) writes:
>     One program segment I have never tried, but supposedly works
>   on at least the IBM 3081D, is the statement BALR 12,12.
>   This instructs the assember to branch to 12 and load the value
>   of 12 and exucute it. Well, the command 12 is BALR, so this 
>   essentially tells itself to BALR to itself, and excute what is
>   there, which is a BALR and you get the picture. :-)

This sounds like an imp.  ALA corewars.  

Jochen Fritz ("Noah")

PS There is a 3090 on campus, I might try that :-)

In article <11212.664...@mts.rpi.edu> Greg_d...@mts.rpi.edu (Commander Krugannal) writes:
>
>     One program segment I have never tried, but supposedly works
>   on at least the IBM 3081D, is the statement BALR 12,12.
>   This instructs the assember to branch to 12 and load the value
>   of 12 and exucute it. 

Nope, this isn't BALR at all. You might have had an interesting
program, but this isn't it....

>     Well, the command 12 is BALR, so this 
>   essentially tells itself to BALR to itself, and excute what is
>   there, which is a BALR and you get the picture. :-)

I don't see what this has to do with my original posting on the
topic of "revenge" anyway..

Along a similar line, though, is the execute instruction, which
IS a command to execute the target instruction "out of line".
Apparently on the 709x series of computers, the single instruction
sequence XEC * (execute this instruction) caused the CPU to get
stuck in the fetch part of the instruction cycle (it never quite
succeeded at obtaining the instruction that was to be done).

The console STOP key was only polled after the completion of an
instruction cycle, so was of no effect during XEC * processing.
It was necessary to power off the machine to break the loop.
Subsequent IBM machines which had an execute instruction also
had an interrupt (program exception) if the execute target was
itself an execute op. I guess they learned something along the
way   :-)

Michael Stimac
.....sun!oliveb!tymix!stimac

In article <11...@csli.Stanford.EDU>, po...@csli.Stanford.EDU (Bill
Poser) writes:
< [In reference to story about code that jumps to itself.]
< 
< A friend of mine told me about how he tried this on an old discrete
< component machine. He tried it and the program merrily looped away.
< Eventually he got tired of this and tried to halt the program. No luck.
< During such jumps, the machine disabled interrupts. So he decided to
< halt the machine. That just sent an interrupt, so it didn't work either.
< He thought cutting the power, but was worried that an abrupt power-down
< would cause a melt-down. Finally, he went and got one of the technicians.
< He thought for a minute and asked at what location the instruction had
< been loaded. Then he opened up the machine, found the logic for that
< location (remember, this is a discrete component machine - you can
< locate individual transistors) and shorted the collector to the
< emitter with a screwdriver. This is what is known as "programming down
< on the bare metal".

On a Data General NOVA (and on the Eclipse also, I believe) you
could have an instruction do an infinite indirect memory reference,
where the contents of the memory was the address of that location.

Interrupts are only acknowledged *between* instructions, and the STOP
switch (toggle switch) is only effective after an instruction is FINISHED,
and since the instruction isn't finished until it reaches the end of the
indirect chain (infinite).... you can't stop the CPU by pressing STOP!

Actually, you can press *RESET*, which DOES allow stopping in the middle
of an instruction (FORTUNATELY!)

_____________________________________
Brian V. Smith    (bvs...@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.

In article <11212.664...@mts.rpi.edu> Greg_d...@mts.rpi.edu
(Commander Krugannal) writes:

 >     One program segment I have never tried, but supposedly works
 >   on at least the IBM 3081D, is the statement BALR 12,12.
 >   This instructs the assember to branch to 12 and load the value
 >   of 12 and exucute it. Well, the command 12 is BALR, so this 
 >   essentially tells itself to BALR to itself, and excute what is
 >   there, which is a BALR and you get the picture. :-)

Technical correction: The above is totally wrong. The instruction does
not branch to 12, it branches to the address contained in register
twelve, which could be anything, anywhere.

It saves the address of the next instruction into register 12, so that
a subroutine can branch to it.

Now, on VM/CMS, the address in register 12 at entry point to a routine
happens to be the beginning address for the routine.  So if this is a
single instruction program it will branch to itself at least once.  I
think, though, that it will then branch to the following instruction.

The original intention seemed to be to construct an endless loop.
There is nothing magical or uninterruptable about such a loop
(especially this one, although the execute on the 7094 was
interesting), and I leave it as an exercise for the reader to
construct one in their favorite high level language or assembler.


-- 
Nick Simicich --- uunet!bywater!scifi!njs --- n...@ibm.com (Internet)

>>>>> On 20 Dec 89 18:23:00 GMT, Greg_d...@mts.rpi.edu (Commander Krugannal) said:

Moore>      One program segment I have never tried, but supposedly works
Moore>    on at least the IBM 3081D, is the statement BALR 12,12.
Moore>    This instructs the assember to branch to 12 and load the value
Moore>    of 12 and exucute it. Well, the command 12 is BALR, so this 
Moore>    essentially tells itself to BALR to itself, and excute what is
Moore>    there, which is a BALR and you get the picture. :-)

It's been 20 years since I've written assembler, but you've been led
astray.  Branch And Link Register (BALR) is intended to facilitate
subroutine calls; it loads the address of the next effective pc into
the first register and branches to the address contained in the second
register and

a) that pc will be the one following the BALR
b) the destination address may well have been computed before the pc
   being stored (I don't recall the order of address evaluation) and,
   even so,
c) the data being stored is a pc, not the BALR instruction itself and,
d) the 360/370/etc series has a separate accumulator and memory space,
   so one cannot branch to a register.