some ideas for revamping numeric bytecodes
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
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. - 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. - 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?". 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! - 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". 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@haskell.org http://www.haskell.org/mailman/listinfo/yhc
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@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
participants (2)
-
Robert Dockins -
Thomas Shackell