Re: [PORTS] RedHat6.0 & Alpha

1) The reason why for -mieee is that if u care for some of the 'rare' floating point
exceptions ( as defined by alpha floating point hardware ) then u want to handle
them - as per ieee specifications to give u the correct ieee result. When the
processor cant handle the exceptions it (can ) traps to software assist routines
( hidden in the kernel ). But in order for the kernel to fix the exception u have to
stop the pipeline as close to the problem, so u can backtrace the user pc ( which is
by now quite a few instructions ahead of where the exception occured ) to the point
where it occured to see what register needs to have the correct value inserted.
Without the -mieee, the compiler will not arrange the float operations so that
it can be backstepped when a fault occures. The kernel then cannot fix the problem,
and forces a floating point exception onto the program. Death usually follows.
Therefor only do -mieee where u need to. ERGO can this flag be set individually
as per each individual makefile, and not as per ./configure ?
2) Then I want to report a bug - HAS_LONG_LONG in one of the 'c' files needs to be
turned on - I think there is only one - also for RH6.0/alpha. I dont think that
RH6.0/alpha has long long as a type and just uses long to define a 64bit quantity
3) Then can I presume that Absolutetime/Relativetime in nabstime.h will be changed
to int32?

Bruce Momjian wrote:

> > Well, a reply, anyway
> >
> > 1) reltime & abstime values are stored in the DB as 4 byte values. The
> > definitions for abstime&reltime are also stored in the DB ( this from empiracle
> > debugging ) . If you do not plan to embrace the notion of #of seconds >
> > 2^(32-1), and you dont want to alter the DB notion that storage is 4 bytes then
> >
> > typedef int32 Absolutetime;
> > typedef int32 Relativetime;
> >
> > would appear to be most preferable & more stable (majic #'s work ) than
> >
> > typedef time_t Absolutetime;
> > typedef time_t Relativetime;
> >
> > This is not a complete solution , as there are still some sign extension
> > problems as demonstratable by the regression tests.
> > If you want to use 64bit Absolutetime & reltimes, then you should adjust (
> > or make more abstract ) the concept of abstime&reltime. BUT
> > THIS IS NOT A PORTING ISSUE! I would just like to get the abstime*reltime to
> > behave much like the 32bit folks.
>
> Makes sense. Using time_t does not make sense if we are forcing
> everything to 4 bytes.
>
> >
> > 2) Can u add HAS_LONG_LONG to $(CFLAGS)
> > I dont have long long, but it turns on some code ( somewhere ) that fixes
> > another problem.
>
> Check configure. It runs a test to see if long long works, and sets that
> in include/config.h.
>
> >
> > 3) -mieee informs the egcs compiler fot the alpha to inject 'trapb'
> > instructions at various places in a floating point computation. The trapb is a
> > pipeline stall forcing the processor to stop issueing instructions until all
> > current instructions in the pipeline have executed. This is done to capture a
> > possible 'fault' at a resomable time so you can backtrack to the instruction
> > that faulted and take some corrective measure. There are also rules for
> > backtracing, and repairing. The usage of -mieee inserted these trapb's all over
> > the place. The current egcs compiler appears to do a better job at it For
> > purely int operations, then a module need not be enhanced by the -mieee switch.
>
> I am stumped on why we even need -mieee, but someone supplied a patch to
> add it.
>
> >
> > 4) I'd give u some patches, but still getting the regression tests to work.
> > Where do I get 6.5.1, so I can work with that as a base
>
> Go to ftp.postgresql.org, and get the "snapshot". That will be 6.5.1 on
> July 19th.
>
> > 5) What is the floating point rounding set to ( up/down ). There seems to be an
> > extra digit of precision in ur i386, where the alpha port appears to round up (
> > and have 1 digit less :( )
>
> Not sure where that is set. Would be fpsetround() on BSD/OS, however, I
> don't see us setting it anywhere, so my guess is that we are using the
> OS default for this.
>