Fixed point types.

[chriseth]

Closes #409

[ekpyron]

I wonder whether it'd be wise to decide up front if we want to never support 256-bit multiplication on these or how to deal with that wrt overflows - having multiplication for 256-bit ones behave differently from all others might be rather confusing... (or maybe not, not entirely sure...)

[chriseth]

@ekpyron why would you say multiplication behaves differently? Currently we have "arithmetic operations are performed in two's complement / modulo 2**bits". For uint64 for example, the actual computation is done with higher bit width and then truncated. This would be the same for fixed256x80. Essentially for all types and operators, we perform the operation in arbitrary precision arithmetics and then truncate.

[ekpyron]

@ekpyron why would you say multiplication behaves differently? Currently we have "arithmetic operations are performed in two's complement / modulo 2**bits". For uint64 for example, the actual computation is done with higher bit width and then truncated. This would be the same for fixed256x80. Essentially for all types and operators, we perform the operation in arbitrary precision arithmetics and then truncate.

And how would you do that? I'm not saying it has to behave differently, but that it's worth a thought what it would look like for the 256 bit type before defining that we do things in arbitrary precision only to later notice that that's too much hassle for 256-bits.

[chriseth]

We have a "larger than word size" multiplication algorithm in the wasm transform. I would do it in a similar way.

[ekpyron]

We have a "larger than word size" multiplication algorithm in the wasm transform. I would do it in a similar way.

Ok, fair enough. And we're sure that's the way to go? I mean it would mean that the 128-bit version is cheaper, that's something we'd probably need to communicate, because people might assume that the 256-bit version is the least hassle (and I recall that people don't read documentation ;-)). But yeah, I'm just wondering, I'm fine with going that way! The alternatives to always revert on intermediate value overflows or to have only the 256-bit version do that are both probably significantly worse, so probably the best option regardless.

[ekpyron]

I mean of course just not having a 256-bit version could be a viable and maybe even quite reasonable version actually...

[chriseth]

fixed will be an alias for fixed128x80 correction: fixed128x18 - 128 bits overall and 18 decimal places after the decimal point.

[axic]

I've looked into reviving this and I think we may be better off splitting this into multiple steps/PRs:

• semantic tests (and codegen fixes) for all kinds of assignment and input/output (this also needs isoltest improvements)
• ... for constant expressions
• ... for fixedpoint arrays
• ... for conversions
• ... for arithmethic

Pushed some tests and the result is:

• state_variables: Fixed point types not implemented.
• variables: Line 11: Unexpected character: '.' (isoltest missing support
• arrays: Error: Contract or array type expected.
• constants: Fixed point types not implemented.

[chriseth]

Suggested change

	// g(fixed128x80,fixed128x80): 9.871, 88888888.0 ->
	// g(fixed128x18,fixed128x18): 9.871, 88888888.0 ->

[chriseth]

Replaced by several independent PRs. The codegen for operators is not in the other PRs but it is easy to recreate.