[Yhc] some ideas for revamping numeric bytecodes

Robert Dockins robdockins at fastmail.fm
Mon Aug 7 11:47:11 EDT 2006


On Aug 7, 2006, at 6:07 AM, Thomas Shackell wrote:

> Hi Rob,
>
> Yes some operations are represented through bytecode operations and  
> some through FFI calls.
>
> Your proposal is an interesting idea but, as I see it, it does have  
> some disadvantages:
>
>   - It's not very extensible, if we need to add more operations and
>     we've run out of reserved codes then it would be necessary to  
> change
>     the bytecode format.

This is true.  On the other hand, I scoured the standard libs looking  
for primitive ops to support.  I think the list is pretty complete.

>   - It would introduce instructions with complex bit packed arguments.
>     It's generally reckoned to be a good idea to avoid bit packing
>     arguments in an interpreter because it's actually really expensive
>     (and fiddly) to decode them.

Also true, but you could interpret it via tables or using the same  
techniques used to decode the byecode op in the first place.  That  
is, you don't have to interpret them by fiddling with the packed bytes.

>   - It's a little more symmetrical than the current system but it is
>     still quite asymmetrical; for example it could be argued "Why  
> make a
>     special case for the numeric functions?".

Because it embeds more of the semantics of the program into the  
bytecode, rather than calling out to the "black box" of the FFI.   
This is good for program transformations, including the ultra-spiffy  
JIT compilation engine that I'm sure everyone has at least imagined  
could exist, and for offline static compilation.  If I were writing a  
JIT engine (which I'm not, admittedly), I'd be very upset if I had to  
call out to the FFI for all the numeric operations except add, minus,  
multiply and divide, especially if it inhibits constant propagation/ 
folding and strength reduction and other nice things I'd like to do.   
Of course, the other thing I'd probably be upset about is array  
operations, but that's another story.

>     For example, compare putChar with floating point signum; putChar
>     might be called hundreds of times in one program but I've never  
> even
>     seen a program that actually uses floating poing signum!

Well, its true that putChar is much more frequently used, but it is  
also, by nature, quite different from signum.  It represents a  
nondeterministic interaction with the environment, and is inherently  
"black box" in nature.

>   - There's nothing very wrong with the current system. It is a little
>     asymmetrical but it's not a big problem. There would be more of a
>     case to removing the numeric bytecodes and just using the FFI
>     interface (as Hugs does) but I'm a big fan of:
>                "if it aint broke, don't fix it".

This is certainly a persuasive argument.  However, I think that a  
major bytecode reengineering will be necessary some time in the  
future, if Yhc is going to support the following desirable features:

* Verification
* Data.Dynamic (ie, type-safe casts)
* GADTs
* Type-safe runtime code loading


I'd certainly not suggest that this numeric proposal be implemented  
unless there is some concrete demand for it (ie, somebody starts  
working on a JIT engine), or the bytecode set is undergoing a major  
revision for some other reason.


> So I would vote in favour of leaving it as it is, but please keep  
> the suggestions comming :-)

>
> Thanks
>
> Tom
>
>
> Robert Dockins wrote:
>> Hello,
>> A few weeks ago I was thinking about the strange situation with  
>> Yhc's numeric primitives.  Some of them are in the bytecode set,  
>> and some are handled through the FFI (at least I think that's  
>> what's happening).  Thinking about it led me to decide it would be  
>> better to somehow represent all the numeric primitives as bytecode  
>> operations.  So, I wrote up a proposal.  Anyone who is interested  
>> can check it out at:
>> http://haskell.org/haskellwiki/Image:Num-bytecodes.txt
>> The ideas are about 3/4 baked (which is to say, somewhat more than  
>> half-baked ;-) )  I think the integer stuff is pretty good, and  
>> the floating point is OK.  I'm less sure about the pointer stuff.   
>> At any rate, I thought I'd share the proposal so it doesn't become  
>> completely lost in the dark recesses of my home directory.
>> Rob Dockins
>> Speak softly and drive a Sherman tank.
>> Laugh hard; it's a long way to the bank.
>>           -- TMBG
>> _______________________________________________
>> Yhc mailing list
>> Yhc at haskell.org
>> http://www.haskell.org/mailman/listinfo/yhc
>



Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG





More information about the Yhc mailing list