Github Add support for const operands and options to global_asm! by Amanieu · Pu...

Contributor

Is it intended that this uses a decimal representation of the float as opposed to writing out a hex value representing the encoding of the float? I don't recall seeing any other way to represent floats in assembly than their hex encoding.

I'm worried mostly that encoding a float here could lead to double-rounding resembling issues – we had some of those in the past where the Rust's formatting algorithm used to produce very slightly different results than those produced by C, but both still "correct". Encoding the bits representation of the float would make me much more comfortable with this.

Contributor

That said it seems preexisting… so

Author

Contributor

I'm actually considering getting rid of float constants and only supporting integers. It would work better with typeck too.

Contributor

Hm, so I have questions about this. Many architectures have separate instructions that sign-extend or zero-extend the constant operands from, say, 12-bits to the register bit width. Do i recall correctly that otherwise the assembler implementations don't particularly care about whether the constant is represented as a wrapped signed integer or a unsigned integer, as far as it is in range of the maximum bit width for the instruction?

This is probably the correct implementation regardless, but it seems like it could result in some weird action at a distance behaviour.

Author

Contributor

Our job in rustc is to emit the given constant as a string. The actual interpretation of that string is up to the assembler and is not our problem.

The most sensible way of handling this is to format based on the original type of the value, just like format! does.

Contributor

The problem is exactly in how different pieces of software interpret the same decimal float string. There's very often a difference between different interpretations. Outputting the float as a hexadecimal bit representation avoids this issue entirely and the only party in control of what float ends up being encoded in the binary is Rust. Which sounds like an improvement to me.

Contributor

Allowing pointers may be useful for e.g. embedded use-cases where people might want to refer to e.g. peripherals.

Author

Contributor

There is a separate sym operand type for this which inserts a symbol name. It is not supported in global_asm! yet but will be in the future.

Contributor

Ah, I meant something different. Like

const GPIOA: *const u32 = 0x8000_4200;

and then users trying to use that pointer as-is. Symbol isn't quite usable here because placing the symbol in the right place would require linker shenanigans people don't generally love all that much.