From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie>, Andres Freund <andres(at)anarazel(dot)de>, Noah Misch <noah(at)leadboat(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: AIX support - alignment issues |
Date: | 2022-07-08 04:26:15 |
Message-ID: | CAM-w4HPxEmttAuOP7SR4_qq8WzNu+Ww=r6Za30Vq_-bsMPE12Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 7 Jul 2022 at 22:36, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> * Since Greg Stark's magnificent Vax talk[1], we became even more
> dependent on IEEE 754 via the Ryu algorithm. AFAICT, unless someone
> produces a software IEEE math implementation for GCC/VAX... if I had
> a pick one to bump off that list, that's the easiest to argue because
> it definitely doesn't work.
Yeah that's definitely true. I think you could possibly build with a
software fp implementation but then you would have to recompile libc
and any other libraries as well.
If it was worth spending a lot of effort we could perhaps separate the
Float4/Float8 data type from the core C code floating point and
compile with just the former using soft floats but use native floats
for core code. That's probably way more effort than it's worth for VAX
but it would conceivably be worthwhile if it helped for running on
some embedded platform but I don't think so since they would
presumably be using soft floats everywhere anyways.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2022-07-08 05:06:40 | Re: Support TRUNCATE triggers on foreign tables |
Previous Message | Tom Lane | 2022-07-08 04:24:36 | Re: AIX support - alignment issues |