[Mono-dev] conv.r.un opcode

Kornél Pál kornelpal at gmail.com
Mon Dec 15 16:17:14 EST 2008


 > Stack type F is always float64.

This is an implementation detail because the standard explicitly permits 
F to be "wider" than float64.

I am confused because if conv.r.un pushes a float64 compatible 
representation why do both csc and mcs couple conv.r.un with a conv.r8?

I tend to believe that conv.r.un is specified to convert the value to a 
float64 compatible representation and C# compilers just add an extra 
conv.r8 that is not necessary even when F is not exactly float64.


Rodrigo Kumpera wrote:
> Stack type F is always float64.
> Your confusion may come from the fact that interger values on stack can 
> be eithet signed or unsigned. So each opcode has to specify how to 
> handle the value.
> But your view that conv.r.un could be better named as conv.r8.un is 
> correct, thou it only works with integers on stack.
> The point of conv.r4 or conv.r8 on a F value is to be precision consistent.
> 2008/12/15 Kornél Pál <kornelpal at gmail.com <mailto:kornelpal at gmail.com>>
>     Hi,
>     I have read the ECMA specs regarding conv.r.un and I found that
>     conv.r.un converts an unsigned integer either to float32 or to float64.
>     The stack only has an F type and the range of F >= than the range of
>     float64.
>     Summarizing the above I believe that the standard specifies that
>     conv.r.un is conv.r8.un in fact.
>     On the other hand both MS and Mono compilers use conv.r.un and conv.r8
>     in pair.
>     If I assume that F is not the same as float64 can I safely assume that
>     conv.r.un converts to a float64 or should I assume that it is F that may
>     have wider range and/or precision than float64?
>     Thanks.
>     Kornél
>     _______________________________________________
>     Mono-devel-list mailing list
>     Mono-devel-list at lists.ximian.com
>     <mailto:Mono-devel-list at lists.ximian.com>
>     http://lists.ximian.com/mailman/listinfo/mono-devel-list

More information about the Mono-devel-list mailing list