Go To in Woodstocks
|
05-19-2016, 11:46 PM
Post: #11
|
|||
|
|||
RE: Go To in Woodstocks
Hi,
I set up the 67 compiler and emulator to work as follows for the [if..go to] scenario. 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) It would seem logical then that the [if] statement is the key. I'm sure the original designers would have expected that programmers after adding an [if] statement, would follow up with a [go to] statement, otherwise the [if] becomes redundant. 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. cheers Tony |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)