| *** petr has joined #io | 00:02 | |
| *** codestorm has joined #io | 00:04 | |
| *** endou_____ has joined #io | 00:05 | |
| *** petr_ has quit IRC | 00:13 | |
| *** endou____ has quit IRC | 00:13 | |
| *** ElMonkey_ has quit IRC | 00:13 | |
| *** c74d has quit IRC | 00:35 | |
| *** c74d has joined #io | 00:38 | |
| *** codestorm has quit IRC | 02:17 | |
| *** ElMonkey_ has joined #io | 05:05 | |
| *** bomma has quit IRC | 05:05 | |
| *** bomma has joined #io | 05:06 | |
| *** petr has quit IRC | 06:24 | |
| *** petr has joined #io | 06:24 | |
| *** endou____ has joined #io | 08:04 | |
| *** bjz has quit IRC | 15:10 | |
| *** bjz has joined #io | 15:14 | |
| jer | prologic, yup, what's up? | 16:23 |
|---|---|---|
| *** TheMonkey has joined #io | 17:42 | |
| prologic | jer, oh hey! | 20:54 |
| prologic | jer, see backlog here: http://irclogs.shortcircuit.net.au/%23io/2014-09-10.log.html#t07:06:07 | 20:54 |
| jer | i think i understand what you mean, but to be clear, are you talking about the interpreting of bytecodes, what representation that goes into? | 20:57 |
| jer | the job of the virtual machine is to take the higher level representation, and to bridge the impedence mismatch between the large bit string that is your program, and your source input language | 20:58 |
| prologic | yes | 20:58 |
| jer | there's information that you can encode in your bytecode that will give you a better idea at runtime, as to how some value may be treated, or variable | 20:58 |
| prologic | just kind of feels like you build an ast | 20:58 |
| jer | so for instance, instead of creating a whole number object | 20:58 |
| prologic | which is somewhat similar to the object model | 20:58 |
| prologic | sort of | 20:58 |
| prologic | but it's now been days later since I said this | 20:58 |
| jer | you might instead, tag it in such a way and embed the value in the untagged portion of the number | 20:58 |
| prologic | and I think I see the "slight" difference | 20:59 |
| jer | thus reducing your object footprint for numbers down to a simple mask operation | 20:59 |
| prologic | ast is about parsing and representation | 20:59 |
| prologic | object model is about runtime behavior | 20:59 |
| jer | yeah so object model wise | 20:59 |
| jer | really depends on what you'er after | 20:59 |
| jer | but typically you want to decouple these two things | 20:59 |
| jer | so for instance, your runtime will live as a library in the programs memory space somewhere which isn't really important, as the linker will take care of this | 21:00 |
| jer | if that's your VM which is the universe for the program, then cool, same logic applies | 21:00 |
| prologic | *nods* | 21:00 |
| prologic | next question/thoughts I had was around specializing bytecode insturctions | 21:01 |
| prologic | or building behaviors/functions on the internal object models that represent the oriignal source program | 21:01 |
| prologic | if you know what I mean | 21:01 |
| prologic | it seems to me that you could do it either way | 21:01 |
| prologic | but the former would mean the compiler would have to treat certain patterns of message in a special way | 21:02 |
| jer | honestly, i think you'll make it easier on yourself if you don't try and adhere too closely to what io is, not even in spirit | 21:03 |
| jer | =] | 21:03 |
| jer | io is notoriously hard to make efficient, and while compiling it into a sequence of instructions isn't hard, it's pointless. | 21:03 |
| prologic | sure :) | 21:03 |
| jer | we actually had a message compiler at one point | 21:04 |
| jer | quag wrote one | 21:04 |
| prologic | *nods* | 21:04 |
| jer | this was in the pre-git days i think | 21:04 |
| jer | we were still using darcs back then | 21:04 |
| prologic | but you do get what I mean right? | 21:04 |
| jer | ok, well it's not really the same structure though | 21:04 |
| prologic | compile things like x = 1 to a special set of bytecode as opposed to just loading and pushing messages and performing evaluation at the interpreter level | 21:05 |
| jer | for instance, your frontend, may compile code down in the backend that is optimized, has certain assumptions made about it which is formally verifiable by the compiler frontend | 21:05 |
| prologic | *nods* | 21:05 |
| jer | you may even get a more compact bytecode representation by throwing out some info that's not useful in bytecodes that is required in the frontend | 21:05 |
| jer | this is why they're separate. not saying oyu won't see similarity, and the closer you stay to io-like, the more you will see what feels like duplication | 21:06 |
| jer | but it's not really intended to be that way | 21:06 |
| prologic | *nods* | 21:06 |
| prologic | I think that's largely because Io | 21:06 |
| prologic | or language like it are so simple at their core really | 21:06 |
| prologic | for instance I've come to the conclusion I can in theory get away with only 3 instructions (not including pushing/popping the stack frame ala continuations) LOAD, EVAL and END | 21:07 |
| prologic | doing lookups and activations on the object models themselves of the things we create from LOAD/EVAL | 21:08 |
| jer | honestly, that's why i'd be more interested in building something ahead of time first | 21:08 |
| jer | then worrying about interpreting it | 21:08 |
| jer | because it removes you from having to build the virtual hardware to run a custom ISA | 21:08 |
| jer | let alone designing that ISA | 21:08 |
| jer | =] | 21:08 |
| jer | i honestly think it easier to target native code, or an existing VM than to build your own | 21:09 |
| jer | my last VM was "wee" -- intended to be a very tiny runtime library to support an io | 21:09 |
| jer | and it worked off an entirely different type of runtime than io has | 21:10 |
| jer | things like blocks were still real objects | 21:10 |
| jer | but it was built for space optimization | 21:11 |
| prologic | *nods* | 21:11 |
| prologic | I do see what you mean | 21:11 |
| jer | i used a lot of tagging for primitive objects | 21:11 |
| jer | as such, required allocations to be aligned | 21:11 |
| jer | simplified messages tremendously | 21:11 |
| jer | and an object's vtable was stored as a separate product type | 21:12 |
| jer | which was fixed at generation time | 21:12 |
| prologic | ok | 21:12 |
| jer | to "open" it required special work, but was doable. | 21:12 |
| prologic | have to dash for the bus to work | 21:12 |
| jer | but i did this so i could change the way lookup worked | 21:12 |
| prologic | but thanks for the insight :) | 21:12 |
| prologic | very helpful | 21:13 |
| jer | with the idea of compiling to native code | 21:13 |
| jer | sure | 21:13 |
| jer | later man | 21:13 |
| *** gatesphere has joined #io | 21:16 | |
| *** gatesphere has quit IRC | 23:40 | |
| *** petr_ has joined #io | 23:50 | |
| *** petr has quit IRC | 23:52 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!