"John Femiani" <JOHN.FEMIANI@asu.edu> writes:
I have seen Phil's code, but I wonder if Maurizio is willing to offer a peak at the proto-fied library he is working on as well?
I've no problems in making my code available as I go, but I'm still working on porting to proto some of the code I did write before proto was widely announced. If I can finish that port I'll post the result as 'work in progress' around the end of next week. That part was using my horrible homegrown expression templates, but had the nice property of working, something you cannot underestimate in software development. And I was getting nice vibes from looking at the assembly code produced. In the meantime I might write up something on the features I'm trying to implement, both for discussion and as a starting point for documenting my code. But I'd like to stress an important point: I'm not in the immediate working on a boost library, rather I want to replace the SystemC datatype implementation with something: - much shorter (right now the OSCI SystemC implementation weights at about 15K lines of code, I want to get as near to zero as possible) - more efficient (by using expression templates there more domain specific optimizations that can be done) This means that I've to do a few things that are probably of no interest to a wider community. For instance in SystemC you have a class sc_int<N> that behaves like you'd think, but it is defined to inherit from a class sc_int_base that takes the width as a constructor parameters. This width cannot be changed after construction, so you'd question why to have it at run time at all. Still I need to allow bounds to be optionally specifiable at run-time. For now I'm doing good and you pay for bounds only when you actually want to specify them at run-time, otherwise (with decent EBO) they just disappear. Similary, there're things that might be interesting for some people and I'm not implementing immediately (but leave hooks in the framework). For instance I'm allowing multiple logical representations for integers, but at the beginning I'll implement only magnitude (for unsigned) and two_complement (for signed). Later, I'll support sign-magnitude and one-complement. I've ruled out for instance polarized numbers (e.g. numbers w/ offset as used often in exponents of floating point values) because it would be a place where the logical representation needs to be parametrized. Also, for now I'll support access to bitfields inside numbers only to the extent required by SystemC. The right thing to do would be to allow for the specification of a phyisical layout (simple application is the definition of different endianesses than the host machine. I did it with a previous employer and I know how to design the framework to allow for the plugin of this part later, but is a big project on its own.
I am curious to see the different approaches and also I wonder if either of you are willing to consider non power-of-two scaled values.
Not in the first implementation. Later I'd like to let people specify bounds as a MIN and MAX value, rather than bitwidths, but this wouldn't be what I think you mean here. If you allow for arbitrary scales, you get into what Ada called 'the small'. This is basically the weight of the lsb in your significand. And even them, they required compilers to implement only power of two. There're nasty things that happen with arithmetic when numbers with arbitrary (and different) smalls are mixed. Just to give an idea, when you add two values with a different binary scaling factor you need to align the decimal point, and you do this by shifting one of the two (you chose which so that you do not loose bits, when you're allowed to grow the significand). If the 'small' is arbitrary, this alignment becomes messier and people have fought many papers on the resulting error in arithmetic operations. So, no I do not think I want to go there.
For instance images are commonly stored using 8bit integers, but with the assumption that 255 is actually 'one'.
As I said before, this seems easy untill all numbers in the expression shares the same 'small', but in general is very difficult. There might be ways to get what you need in this case by allowing the user to specify optional functors that are used to convert to/from builtin types. But it requires further thought. Which is why probably I should post a list of features open for discussion, regardeless from what I'll be able to implement right now.
Also dollars can be apparently by treated as scaled<int64_t, 100> in order to prevent some floating point errors. If the library included something like scaled<uint8_t, 255>, along with operators and their return types as discussed for fixed points, then I would personally be extremely interested.
Well, next C++ and C standard will have numbers with decimal representation exactly for that. I haven't followed recent developments, but that was the impression I got.