[Ecls-list] Immediate short-float for ECL

[Lars Brinkhoff]

"Juan Jose Garcia-Ripoll" <juanjose.garciaripoll at googlemail.com> writes:
> I had a look at your code.

Thanks for the feedback!

> You are clearing some bits in the floating point number to replace
> them with the type tag.  That does not seem very safe in 32-bit
> computers.  Isn't the last bits where the exponent is stored?

On the x86, which is what I'm developing on, the last bits hold the
least significant bits of the mantissa, so that's safe.  On a big-
endian machine, I would believe that loading a 32-bit word would also
make the least significant bits appear last in the register, but I
will be sure to verify this on my PowerPC machine.

On machines where clearing the last bits isn't safe, obviously some
other way to maintain the integrity of the floating-point value would
have to be used.  The important thing is that the two least
significant bits in the mantissa are discarded, not some other vital
part of the float.

(Maybe you haven't tried running the patch?  Even though it's not
finished, it's quite stable, at least in x86-linux.  It builds and
runs the test suite without crashing.)

> I think that your code is much better suited for 64-bit environments,
> where one has plenty of bits to spare, but this code wouldn't make use
> of those extra bits:
> +               union { float flo; cl_fixnum fix; } _tmp__val_; \
> +               _tmp__val_.flo = (n);                           \
> +               _tmp__val_.fix &= ~IMMEDIATE_TAG;               \
> +               _tmp__val_.fix |= IMM_SHORTFLOAT_TAG;           \
> +               (cl_object)_tmp__val_.fix;                      \
>
> Perhaps something like
>                  struct { int32_t fix; float flo } _tmp__val_;
> would be better there.

That may be true.  I haven't considered 64-bit machines yet.  (But
isn't cl_fixnum 64 bits in a 64-bit system?)

> I would also replace the name immediate-floats with short-float and
> single-float (t_imm_shortfloat -> t_shortfloat).

Right.  The use of "immediate" is just temporary.

> In 32-bit environments, when configured with --enable-short-floats
> they would be different and have different tags.  In 64-bits there
> would not be short-floats, all single-floats would be immediate
>
> What do you think?

Yes, that's exactly what I have imagined would be the ideal end result.

> and the tags would be the same (t_shortfloat == t_singlefloat), so
> that the compiler collapses the code for short-floats and
> single-floats.

Yes, with careful coding, the compiler should be able to collapse the
unnecessary branches in if-else statements.  Unfortunately, I don't
think it will work with switch statements, where duplicate case values
are considered an error.