I'm not sure what you're seeing or why - perhaps you could show one or two worked examples?
Have you tried running the python emulator, or the javascript one? I think you see enough there to see what's going on.

I get this:

I'm trying to figure out how the architecture works from the verilog code...
In the python emulator, the line of code is still the same...

Hmm - have you noticed there's pcarry, which controls whether the predicate as a whole is sensitive to c, and pzero, which controls whether the predicate is sensitive to z? In the originally quoted table, "Carry pred" refers to the value of pcarry, and same for zero. That is, the columns are the value of the predicate control bit, not the cpu status bit.

As ever, there might be ways to improve the doc.

For the casual onlooker, the idea is that we can do a unconditional operation such as ld, or one only when z is set, with ld.z, or only when z is clear, with ld.nz, and so on. There's the always condition, the nop condition, and six others, which turns out to be quite powerful and flexible. More importantly for one-page computing, it's quite simple.

(We had another goal, of small implementation size, so simple in the implementation is good too.)

In later revisions of the architecture, we could take the 'nop' case and reuse it as an opcode bit, which means we get to double the operation count, with half of them predicated and half of them not.

Ah I see. I was unaware of the instruction variation.

So, suppose you have instruction ld.z. pred_zero would be 1, pred_invert would be 0, and pred_carry would be 0. How will the predicate signal ever be high/true for the ld.z instruction? If,

Then the only way it can evaluate to true is if flag_carry is 1 ...

Thanks a lot for you time and patience!

For whatever subtle reason, it seems the pred bits are negative logic, so for a ld.z you'd have pred_zero as 0, pred_carry as 1, and pred_invert as 0. I think that should work out.

Of course, at assembly level you don't worry about this. But of course the verilog, the assembler, the emulators, the monitor do all need to do it. (For at least some of these CPUs, we wrote (hoglet wrote) a single-stepping disassembling monitor which runs on the CPU, and has to understand enough to disassemble and single step. It was all rather interesting! See here
https://github.com/hoglet67/opc/blob/ma ... /monitor.s
and
https://github.com/hoglet67/opc/tree/master/include
)

Ah ok! Thanks! I'll explore the programs as well =)

There are some arithmetic libraries too - see the 'syslib' files in
https://github.com/revaldinho/opc/tree/master/bcpl

Hi folks!

I've created a schematic for OPC-6. A few signals have been renamed for readability. Let me know if you spot any errors or omissions and I will update accordingly.

Note: This schematic will not pass KiCad's electrical rule check. I've omitted the required bus signal labels in favor of readability.

I have a few lingering questions about OPC-6:

1) Clarification on the concept of "one word instructions" and their relation to the FSM? From the source code:

2) What is the purpose of each of the predicate variations (pred_d, pred_din, pred_q)?

3) I noticed in the emulator you only check for software interrupts. If you were to emulate hardware interrupts, what approach would you take?

From the OPC6 Spec:

All memory accesses are 16 bits wide and instructions are encoded in either one or two words ::



A one word instruction requires only a single FETCH cycle, and so the operand will usually be taken from the register file unless it's a very short immediate.

A two word instruction requires a second FETCH to get the 16bit operand

These states are labelled FET0 and FET1 in the Verilog state machine, with FET1 usually being skipped for the majority of instructions.



Even though it's single page of code, OPC6 does have a short pipeline and the EXEC stage on one instruction overlaps with the FETCH of the next instruction to improve performance.

Consider instructions to be executed in sequence, A:B:C

1. If C is a single word instruction that is to be executed based on the flag states produced by A, then we need to know what condition needs to be satisfied (the predicate) and what is the status of the flags. This needs to be determined at the end of the fetch (FET0) for C, because we are deciding whether or not to EXECute C or just skip straight to the next instruction fetch. However, during FET0 for C, the predicate bits have not yet been latched into the Instruction Register, so the computation uses the predicate bits as they are currently on the databus vs the stable flag bits in the status register. This is labelled pred_din.

2. If C were a two word instruction, the we must complete the second fetch (FET1) for C whether or not the instruction is to be executed. In this case we need to check predicates against flag states at the end of the FET1 cycle. The flags (from instruction A) are still stable and in the status register, but now the predicate bits are no longer on the data bus which is holding the 16b operand instead. The predicate bits however have been latched into the Instruction Register now at the end of FET0. So, we need to compare the predicate bits in the IR this time then vs the stable flag bits in the status register. This is labelled pred_q.

3. Finally if C were a single word instruction and were conditional on the status of the flags at the end of B then we have a slight problem. Execution of B overlaps with the fetch of C, so that at the end of FET0 for instruction C, the flags have not yet been written into the status register by B. So, just as in the first case the predicate bits are on the data bus for C, but now we need to compare these against the yet-to-be-written flags which have just been computed in instruction B. ie we are comparing predicates against the flag data on the 'd' side of the status register rather than the 'q' side. This is labelled pred_d.




This would just need a slightly larger emulator modelling more of a system than just the CPU and memory. Probably checking for a hardware interrupt at the start of every cycle would be adequate, and pseudo-randomly firing the interrupt during specific tests to log the results.

R.

I see, thanks for the explanation!

How does the assembler for OPC-6 handle padding? For example consider the following code:
Is a byte of zero inserted after the byte 0xAA to make GROUP0 equal to a multiple of 16? Thus the programmer has to keep this in mind to avoid unexpected bytes?

At a guess, as it's a word-oriented machine, all values in the assembly source will be interpreted as words. There are no bytes, unless you say it has 16-bit bytes - which amounts to the same thing.

I think this is easily shown with an example




As Ed says, it's a word oriented machine but bytes can be handy use so the assembler processes BYTE statements line by line, packs two bytes to a word and pads out any odd number with a 0 byte.

Ah, thanks - a worked example is worth a thousand guesses. So, I think we can say that the OPC-6 doesn't know about bytes, but the assembler - this particular assembler - does, and is little-endian too. I think we hooked up 8-bit ports to the low end of the word. And we do read and interpret srecords, I think, and had to decide how to handle a bytestream. I expect that was a little-endian approach too.