In message <capyb0ef+-8rvg95y0-mc9qd5mjwwzr_e3hijhd_rbwhqeou...@mail.gmail.com> , Bob Paddock writes:
>I take issues with hardware requiring those kind of resources to keep >track of time. >There are more Embedded Systems today running at well under 100 MHz (or 10 >MHz), >and 128 Floating Point on them just isn't going to happen. Neither is, in my experience, any kind of timekeeping :-) One if the obvious ways to provide a "limited" functionality in my proposed API, is to allow any floating point type, with corresponding loss of resolution. This is an aspect I particularly like, with FP we won't loose range, only resolution. But shelve this issue for now, I want to start with an API which Does The Right Thing, and then move on from there, to see if this is feasible. >"TAI64, covering a few hundred billion years with 1-second precision; >(2) TAI64NA, covering the same period with 1-attosecond precision" See previous discussion about multi-radix formats. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
