Re: Detection of hadware feature => please do not use signal - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Detection of hadware feature => please do not use signal
Date
Msg-id 736756.1732341046@sss.pgh.pa.us
Whole thread Raw
In response to Re: Detection of hadware feature => please do not use signal  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Detection of hadware feature => please do not use signal
List pgsql-bugs
Thomas Munro <thomas.munro@gmail.com> writes:
> (Nerd sniped) No NetBSD here but think a 32 bit kernel should expose
> sysctl machdep.id_isar, which should be an array of 6 ints, and bits
> 16-19 of id_isar[5] should give you the answer:

Huh.  cpuctl's arm32 module knows of machdep.id_isar, but it does not
appear to know that that word exists:

http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/cpuctl/arch/arm.c?rev=1.6;content-type=text%2Fplain

But that developer.arm.com page seems pretty definitive.  Tomorrow
I'll have a go at spinning up a 32-bit NetBSD installation and test
it.  Thanks for the research!

> Since you included <aarch64/armreg.h>, and only care about non-zero,
> couldn't you use the mask from the header, instead of all that
> bitswizzling?

> return (id->ac_aa64isar0 & ID_AA64ISAR0_EL1_CRC32) != 0;

I didn't actually look into that header ;-) ... I was just basing this
on what cpuctl's code does.  That version does look cleaner, at
least for aarch64 --- but given that the field is defined to be
in the same place in the relevant register for each arch, I'm
a bit inclined to keep the bit-swizzling and just have two paths
for getting the register contents.  Unless maybe that header is
also installed in arm32 builds, in which case we could do it as
you show for both arches.  I'll find out mañana.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Detection of hadware feature => please do not use signal
Next
From: PG Bug reporting form
Date:
Subject: BUG #18722: Processing arrays with plpgsql raises errors