On 7 Sep 2016, at 14:45, Hannes Mehnert <[email protected]> wrote: > > hello, > > for several projects (i.e. sequence numbers) I had the need to have > fixed width unsigned integers. Finally I managed to implement them (8, > 16, 32, 64 bit), and would like to hear back from you what you think. > The crucial bit for me is that arithmetic expression expose the carry > bit explicitly (by being t -> t -> t * bool). > > I don't have the plan to complete it with all possible arithmetics > operations (div, pow, ..), since I don't have use cases for these. > > The type t is on purpose a public alias to (int, int, int32, int64), > thus you can use bit operations from these modules directly (and, xor, > or). This also means that you have interoperability with e.g. cstruct. > > The documentation is up at > https://hannesm.github.io/usane/doc/Usane.html , code at > https://github.com/hannesm/usane > > The implementation uses __builtin_add/sub/mul_overflow if available > (since clang 3.4 / gcc 5.1).
The optimisation of the use of builtin functions would probably be drowned out by the extra 2 value allocations happening because a tuple is being returned. Would it be crazy to pass in a bool ref that could be reused to check for overflow? Alternatively, the existing allocation may be -flambda safe and optimisable away for common usage patterns, but I'm not sure this is the case without actually inspecting the output of some tests... Anil _______________________________________________ MirageOS-devel mailing list [email protected] https://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
