Go To in Woodstocks

[PANAMATIK]

(05-19-2016 11:46 PM)teenix Wrote:  I may be wrong, but I cant see any reason for the CPU to work out what type of [go to] instruction is executed as the binary code is the same. Eg (go to, then go to, if n/c go to)

Actually there is no unconditional goto in the CPU instruction set. Therefore the opcode of "goto" and " if n/c goto" are the same. If you want to jump unconditionally, the previous instruction must clear the carry flag like any instruction other than add sub etc. does.

(05-19-2016 11:46 PM)teenix Wrote:  The [67] compiler on detecting any [if] statement (eg. if c[x] = 0), sets an [IF_Detect_Flag]. The next instruction is read and assembled and if the flag is set will test for a [go to] instruction. If it is not, the compiler will generate an error message and exit, otherwise the next CPU code will be the 10 bit value from the [go to] statement.

The [if..go to] sequence can only work within a 1K block of code (10 bit addressing) so the compiler will generate an error if a [go to] target address is outside the current 1K block.

The CPU works similar. If it detects an [if] instruction, it too sets an internal flag.

After any instruction fetch, this flag is tested. If = 0 then the code is treated as an instruction, if = 1, then the 10 bit data is treated as a new PC address and the lower 10 bits of the PC are replaced by the code value and the flag is reset.

This approach seems to work ok in the emulator.

This is the correct approach. Congratulations!

You could add a compiler warning if a "if n/c goto" points to an instruction which is a 10-bit jump, because it is preceded by an " if" instruction. But this does never occur in any original HP code.

Bernhard