Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #126476

Re: Aligned Issue when malloc()

Show all headers | View raw

supercat@casperkitty.com wrote:
> So far as I can tell, the "long double" type was traditionally either a
> synonym for "double", or else an IEEE 80-bit extended type; while there
> may have been some platforms in 1989 that would store an 80-bit type
> with 64-bit alignment (and 48 padding bits), I would expect that it was
> far more often stored with 16-bit or 32-bit alignment (using zero or 16
> padding bits).  Note that if a 64-bit platform supports 32-bit loads and
> stores, there may be no advantage to forcing 64-bit alignment since each
> value would require one 64-bit and one 32-bit operation.
80-bit real type is not really intended for storage. It is even called
"temporary real" in some sources. The point is to be able to convert
to/from int64 without precission loss. (Also, in general, it improves
precision of computations which end up saved as double)

Say you want to multiply a big (from 53 bits in width) integer by a
small real, and save result as int. First you'd lose less significant
bits of the int by converting it to double, and then when converting it
back, you'd have an int with least significant bits zeroed out. Using
extended reals, this problem is avoided.

Least significan bits of mantissa are the most affected by precission
loss on complicated computations, which means that getting your results
in 80-bits will not nescessarely give more accurate results (precise,
yes, but not accurate,) as all fp computations are done internally in
80-bits (well, at least on x86 it's done this way,) so while doubles
stay accurate, because lower bits are thrown away, the extended reals
don't have those inaccure "slack" bits. This is why I think it's not
intended for storage outside of fpu registers.

By the way, on some systems (8088+8087) these can be 8-bit aligned :P

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Aligned Issue when malloc() hwding <m@amastigote.com> - 2018-02-06 01:17 -0800
  Re: Aligned Issue when malloc() Ian Collins <ian-news@hotmail.com> - 2018-02-06 22:41 +1300
  Re: Aligned Issue when malloc() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-06 11:52 +0000
    Re: Aligned Issue when malloc() hwding <m@amastigote.com> - 2018-02-06 04:35 -0800
      Re: Aligned Issue when malloc() Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-02-06 13:48 +0000
        Re: Aligned Issue when malloc() "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-02-06 12:55 -0800
      Re: Aligned Issue when malloc() Richard Damon <Richard@Damon-Family.org> - 2018-02-06 08:52 -0500
        Re: Aligned Issue when malloc() "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-06 09:59 -0500
          Re: Aligned Issue when malloc() supercat@casperkitty.com - 2018-02-06 07:20 -0800
            Re: Aligned Issue when malloc() Robert Wessel <robertwessel2@yahoo.com> - 2018-02-06 11:50 -0600
            Re: Aligned Issue when malloc() Keith Thompson <kst-u@mib.org> - 2018-02-06 11:34 -0800
            Re: Aligned Issue when malloc() Egor <egor@ruby.local> - 2018-02-09 16:20 +0200
              Re: Aligned Issue when malloc() supercat@casperkitty.com - 2018-02-15 08:56 -0800
                Re: Aligned Issue when malloc() Egor <egor@ruby.local> - 2018-02-15 19:35 +0200
                Re: Aligned Issue when malloc() supercat@casperkitty.com - 2018-02-15 11:27 -0800
                Re: Aligned Issue when malloc() Egor <egor@ruby.local> - 2018-02-16 02:48 +0200
                Re: Aligned Issue when malloc() supercat@casperkitty.com - 2018-02-16 08:49 -0800
      Re: Aligned Issue when malloc() "James R. Kuyper" <jameskuyper@verizon.net> - 2018-02-06 09:41 -0500

csiph-web