From ST2975@SIUCVMB.SIU.EDU Thu Nov 26 15:35:15 1992
Received: from calvin.sfasu.edu by umaxc.weeg.uiowa.edu (5.61.jnf/920629)
	  on Thu, 26 Nov 92 15:35:12 -0600 id AA13365 with SMTP 
Received: from SIUCVMB.SIU.EDU by calvin.sfasu.EDU with SMTP (5.59/25-eef)
	id AA26198; Thu, 26 Nov 92 15:29:25 CST
Return-Path: <ST2975@SIUCVMB.SIU.EDU>
Message-Id: <9211262129.AA26198@calvin.sfasu.EDU>
Received: from SIUCVMB.SIU.EDU by SIUCVMB.SIU.EDU (IBM VM SMTP V2R1)
   with BSMTP id 5754; Thu, 26 Nov 92 15:28:07 CST
Date: Thu, 26 Nov 92 15:14:36 CST
From: ST2975@SIUCVMB.SIU.EDU
To: hyperc-l@calvin.sfasu.edu
Subject: Re:pseudo-code interpreter
Status: R

What does opsys8 fix was asked:

There are a whole bunch of j***'s; jeq, jeqz, jne etc., also jmp.

The original opsys cp-interpreter evaluated these and if true,
jumped to the operand following the j*** cp-opcode.  However,
if not true, the C engine pc (program counter) was incremented
by one.

Knowing that the compiler can handle both short and long addressing
modes, i.e., short meaning a byte and relative and long meaning
word or address and absolute, it can be seen that a j*** <byte>
will work ok; the pc is incremented by one and execution continues
on a false condition.  However, what if the j*** is absolute and
a word or address follows?  The pc is still incremented by one
instead of two and havoc occurs.  Is this clear?

What opsys8 does is test the opcode; if its high bit is set, it
increments the pc by 2 on a false condition and if the high bit
is clear it increments the pc by 1.  This is how the interpreter
normally distinguishes between a long or short addressing mode.

Andy W.