From: | Uncle George <gatgul(at)voicenet(dot)com> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>, pgsql-ports(at)postgreSQL(dot)org |
Subject: | Re: [PORTS] RedHat6.0 & Alpha |
Date: | 1999-07-15 00:39:24 |
Message-ID: | 378D2DBC.E078737A@voicenet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-ports |
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.
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.
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.
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
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 :( )
gat
Bruce Momjian wrote:
> > Porting:
> > 1) Seems like -O0/-O1 works best for this machine. It appears u get
> > spin lock errors/timeouts if i optimize at -O3, and -O2
>
> Yes, the 6.5.1 code will use:
>
> CFLAGS:-O -mieee # optimization -O2 removed because of egcs problem
>
> >
> > 2) in nabstime.h, the typedefs AbsoluteTime & RelativeTime ( was that
> > Absolutetime & Relativetime ) should be kept at a fixed ( for all ports
> > ) size like int32. Adjusting it to what ever size time_t becomes leads
> > to problems with 'signed' words v. 'non-signed' extended longwords. For
> > instance the constant 0x80000001 is a negative 32bit integer, but as a
> > time_t it just a large positive number!.
>
> OK, the real problem is that we are using "magic" values to mark certain
> values, and this is not done portably. Can you suggestion good values?
> Can you send over a patch?
>
> > 3) Having problems with sign extension also creates problems for '@ 3
> > seconds ago'::reltime. see #2
>
> Same thing. We should not be using hard-coded values.
>
> >
> > 4) You dont store reltime or abstime as 64bit's into the db. Are there
> > any plans to use 64bit alpha/linux timevalues as reltime & abstime ?
> > maybe reltime64 & abstime64? whats the sql world doing with 'seconds
> > since 1970' if the year is > 2038 ( which is the 32bit signed overflow )
> > ?
>
> Not sure on this.
>
> > 5) having $(CC) -mieee all over just isn't good, particular if no float
> > operations are done. It slows down everthing. Is there a way to limit
> > this in the makefile?
> > gat
>
> What does that flag do, and where would it be needed or not needed?
>
> --
> Bruce Momjian | http://www.op.net/~candle
> maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-07-15 03:08:23 | Re: [HACKERS] header files for spi.h/trigger.h] |
Previous Message | Tom Lane | 1999-07-15 00:34:37 | Re: [HACKERS] header files for spi.h/trigger.h] |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 1999-07-15 03:13:44 | Re: [PORTS] RedHat6.0 & Alpha |
Previous Message | Bruce Momjian | 1999-07-14 15:11:50 | Re: [PORTS] RedHat6.0 & Alpha |