No warning if value is too large for a register

[LoganDark]

Apparently the stm8 x register does not hold a 16-bit value despite having low and high registers(?). This function never results in strop halting:

{
    "tests": [
        {"steps": [{"datum": "a", "set": 255}, {"datum": "x", "diff": 65535}]}
    ]
}

but also it never raises any warning. Same for if diff is arbitrarily large but still small enough for a Rust i32.

[LoganDark]

actually, it seems like strop hangs for a significantly long time even with this input:

{
    "tests": [
        {"steps": [{"datum": "a", "set": 255}, {"datum": "x", "diff": 150}]}
    ]
}

even though using a diff of like 100 completely rather quickly.

Leaving this open since it still doesn't warn for values that don't fit in the register, but I guess I expected too much from strop ATM :P

[LoganDark]

strop's been cooking on the 150 for the past two hours lol. stopping it here

[omarandlorraine]

Apparently the stm8 x register does not hold a 16-bit value despite having low and high registers(?).

It does. If the emulation code in strop doesn't then that's a bug in strop.

{"datum": "x", "diff": 65535}

I can't remember, but it may be that this is expecting a signed representation.

but also it never raises any warning. Same for if diff is arbitrarily large but still small enough for a Rust i32.

This is definitely a bug. Or at the very least, a severe UX problem.

strop's been cooking on the 150 for the past two hours lol. stopping it here

From what I understand, the program you've put is basically an immediate load. It should not matter what the value is, but it does. This point is related to issue #23.

[omarandlorraine]

Can you see what happens if you put the correct value in the list on line 38 of src/machine/stm8.rs?

[LoganDark]

it may be that this is expecting a signed representation.

Bug?

From what I understand, the program you've put is basically an immediate load.

That is correct, with only 1 test case it should just load the value. Well, to be more accurate it should either load the value, or transform that specific input into it.

It should not matter what the value is, but it does.

Oh dear :(

Can you see what happens if you put the correct value in the list on line 38 of src/machine/stm8.rs?

Still doesn't terminate in a timely fashion even if 150 is the only value in the Vec.

[omarandlorraine]

I've just tested that strop does pretty much immediately find the program ldw x, #-1

using this json

{ "tests": [ {"steps": [{"datum": "a", "set": 255}, {"datum": "x", "diff": -1}]} ] }

and this list in src/machine/stm8.rs:

let regs = vec![150, -1];

I don't know why the program ldw x, #150 doesn't get found in the same way. There is definitely a bug here, and probably one unrelated to #23.

[omarandlorraine]

The numbers that work seem to be 127 and less. Points to a data-width related problem, doesn't it.

God willing, I'll do some more testing tomorrow.

[omarandlorraine]

There is pull request #29 which at least has a failing unit test

[omarandlorraine]

Okay. The master branch is now at the stage where if you change the list of possible immediates, then it at least finds a valid program for your example JSON file.

    srl a
    dec a
    dec a
    dec a
    swap a
    neg a
    swap a
    inc a
    inc a
    ldw x, #150
    inc a
    exg xl, a

is an example. There is so much nonsense in there. This is a problem:

• It's possibly a problem with dead code elimination.
• I think it's a problem with a wrong cost function somewhere

[omarandlorraine]

The later versions of the program do not accept a JSON input (this is expected to be moved to a separate crate)

so the issue is being closed.