That's a little alarming actually. If the integer is fixed length that means it may overflow and of course will also truncate in division since it is integer. Just like the compiler, we can't apply an optimization that changes the result the code may produce when overflow and truncation are considered as part of the normal behavior of the type. Sometimes arithmetic is written specifically with overflow and truncation in mind. Since any arithmetic operation may overflow this can really tie your hands. For numerical uses of fixed int we may assume that the programmer designed the code in such a way that overflow should never happen, but for behavioral simulation of hardware with fixed width integer units the correct overflow behavior is the whole point.
Very good point! Looks like I'll have to write that other frontend then....
By the way, I'm really excited about the expression template frontend. I like the elimination of unneeded copies and cutting down on the number of temporaries. I also think it is really cool that you are able to do the arithmetic transformations on the expression template trees. Are you using proto?
No. I started off using Proto, but compile times were so long it pretty much melted down my laptop :-( After some discussion on the list here I switched to a home-rolled expression-template implementation that was designed to minimize the number of templates instantiated (not to mention the amount of meta-programming involved). Even so, compile times can still be quite long if you instantiate lots of different expressions, but it is at least manageable/usable now. John.