[zeromq-dev] s390x support
Steven McCoy
steven.mccoy at miru.hk
Sat Jan 8 05:29:51 CET 2011
On 8 January 2011 11:55, Neale Ferguson <neale at sinenomine.net> wrote:
> The stck instruction stores the TOD clock (each CPU in a complex has its
> own TOD clock). The resolution of the lowest bit is 244.3 picoseconds. In
> the early days IBM used to guarantee that bit 51 of the 64 bit clock would
> be updated every microsecond. These days the lower bits are updated in real
> time to allow nanosecond resolution. However, get the gettimeofday() syscall
> is a “fast” call on System z on Linux (through the use of address space
> tricks it’s effectively a userland call – no context switch). So if it’s
> simpler to use gettimeofday() then that may be the easiest and most
> maintainable path to follow. (The TOD clock was extended to 128 bits about
> 10 years ago as the 64-bit version will roll-over in 2042 and gettimeofday()
> will/does use the 128 bit TOD clock so it is future-proof. It will also
> guarantee a unique value on each CPU.)
>
> So, I’m happy to go with whatever you think is more appropriate.
>
>
For PGM I think you should already be disabling RTC & HPET support for
System Z it would therefore make sense to add TSC onto the list.
The only other assembly in the code is for atomic ops and GCC or Solaris
intrinsics are the preferred option, inline code used for older GCC
versions, i.e. Red Hat 4, and non-Solaris platforms, i.e. OpenSolaris. I'm
ignoring the add-with-carry inline functions as they're not used anywhere
(impl/checksum.h).
So alongside IA64, PowerPC and ARM assembler which is sitting in an old
revision in SVN history somewhere I will currently leave out System Z
assembler unless performance testing results prove significant advantage
*and* the transport is in production use.
Or, simply part of a contract porting project with full platform testing, :D
--
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110108/4a2db29d/attachment.htm>
More information about the zeromq-dev
mailing list