More explicit operand size

[mfld-fr]

See #8 comments

The size of the operand is explicit for string operations with 'BYTE' or 'WORD' qualifiers, but only given though an hint based on the number of digits when displaying an immediate value. Improve the display to be more explicit, in both Intel and AT&T syntax.

[mfld-fr]

First implementation performed by @ghaerr in #10. Action for me: review for any miss in other operation classes.

[mfld-fr]

@ghaerr : Tuned the explicit operation size in commit 1e25716b4332e9cbc2b4820b70dcb40974bf223c, by restricting to memory access only.

[ghaerr]

Tuned the explicit operation size in commit 1e25716, by restricting to memory access only.

Very nice update. I just checked running ELKS again on it and the c)continuous trace output is nicely improved!

On another note, I have been considering whether is makes sense to show when a hardware interrupt occurs, when in instruction tracing mode. The idea is that, since the instruction stream can't show a (hardware-only) interrupt address being pushed on the stack, one cannot actually tell that one has occurred, other than knowing the interrupt vector address and noticing it has suddenly changed.

I was thinking something like the following line inserted in exec_int():

int exec_int (byte_t i)
    {       
    int err = -1;

    // Check interrupt vector first

    addr_t vect = ((addr_t) i) << 2;
    word_t ip = mem_read_word (vect);
    word_t cs = mem_read_word (vect + 2);

    if (ip != 0xFFFF && cs != 0xFFFF)
        {
        // Emulate if vector initialized
        if (flag_trace) printf("[INT %d CS:IP %4x:%4x]\n", i, cs, ip);   <--- insert here

What do you think?

[EDIT: the intention was to show ONLY hardware interrupts, not executed INT instructions... so the above won't quite work. Perhaps the printf could be in a function like hw_int() that then calls exec_int().]

[mfld-fr]

@ghaerr : Yes, that trace could help. Change request tracked by #11.

[mfld-fr]

Review of all operation classes completed. Closing this issue.