At 10:15 PM +0200 on 7/23/99, M. Uli Kusterer wrote:
>>It will be very big -- something on the order of ten to twenty times
>>faster, unless you've got some _great_ optimizer -- i.e., one far better
>>than I've seen!
>
>Doesn't OTVar keep its values as some preferred value? Then there shouldn't
>be that much of a problem. Just a couple of branches more.
Read your PowerPC docs. Unless properly predicted (not sure if they are...)
a branch is _expensive_ Many times an FP div. is faster. [But if predicted
right, it is free]
So, if the branches are jinted right, then all is well. Otherwise, it's slow.
>
>>Better would be to just tell users "you may safely ignore this command".
>>
>>You'll have people even more confused with documented-yet-undocumented
>>commands.
>
>It's just not xTalk-like. That is, I'd hate to see this as part of an xTalk
>standard. I.e. it should be like the Layer Manager. Available but not
>recommended and not supported. We could put it into an "Advanced Features &
>Techniques" chapter of the docs with a disclaimer in front of this like
>"Use at your own risk". OK?
I'm not going to agree to documented unsupported features. We can put it in
an advanced section, but I say we support it.
>
>>Requires more code and one or more passes through the source to do this.
>
> So what? Compilation happens once, this shouldn't be a problem.
>CodeWarrior also makes several passes over the code to optimize it, We'd
>just do the same. for testing, you can use one-pass compilation, and then
>you can activate optimizations.
You'd have to have two different sets of code to pass over it. Probably not
a big deal, though. So long as it predicts right <g>.
>
>>True. But I'd prefer "real" for reals, and "integer" for integers.
>>Otherwise, people would get confused ("but an integer IS a number--why
>>seperate?!"). This way, they'd know that one was intended for decimals and
>>one for integers. Or maybe "decimal" would be a better type name.
>
>I think decimal might work, although people might think that's only the
>part behind the comma. "Real" would work for mathematicians, but no
>computer stuff like "float" or "double".
I think I suggested "real" and "integer". I'm tempted to say "rational" for
mathematical correctness, but that has a quite different meaning in
everyday usage!
