Use a decimal representation for all datatypes in Debugger::printValue

[MaartenS11]

This simplifies the frontend, which no longer has to parse the value of a stack element in hex if it's a float or in decimal if it's an integer. It can just always parse it as a decimal.

Alternatively, we can also represent all of them as hex, but we should be consistent.

[tolauwae]

@MaartenS11 This actually broke Latch tests. This can possibly be fixed on the Latch side, but I want to inquire here first what the reason behind this change was?

[MaartenS11]

@MaartenS11 This actually broke Latch tests. This can possibly be fixed on the Latch side, but I want to inquire here first what the reason behind this change was?

The reason for the change is what basically the description of this PR, but let me maybe elaborate a bit more. Basically, the wasm stack values having a different encoding when they are floats requires parsers to use the "type" field to determine how it should parse another part of the datastucture. I argue that it would be more optimal to just always use the same representation. In this case, the decimal representation of the numbers.

Additionally, the hex values are also formatted without a leading 0x causing parsing to fail using standard json libraries like the one used in MIO. Example:

{"idx":0,"type":"f32","value":3e8}

We could technically keep them hex values if we want, but we should at least add the 0x.

[tolauwae]

Ok so probably I just need to update the latch parser. Seems simple enough. I will push a new latch version to this branch and merge when the tests work again.

Thanks for the extra info.

[MaartenS11]

Ok so probably I just need to update the latch parser. Seems simple enough. I will push a new latch version to this branch and merge when the tests work again.

Thanks for the extra info.

I do wonder, does latch do something special to parse "value" when it's a float without having the 0x prefix? Or does latch just explicitly parse it as a hex number if it's a float?