IRC Logs for #io Monday, 2014-09-15

*** petr has joined #io00:02
*** codestorm has joined #io00:04
*** endou_____ has joined #io00:05
*** petr_ has quit IRC00:13
*** endou____ has quit IRC00:13
*** ElMonkey_ has quit IRC00:13
*** c74d has quit IRC00:35
*** c74d has joined #io00:38
*** codestorm has quit IRC02:17
*** ElMonkey_ has joined #io05:05
*** bomma has quit IRC05:05
*** bomma has joined #io05:06
*** petr has quit IRC06:24
*** petr has joined #io06:24
*** endou____ has joined #io08:04
*** bjz has quit IRC15:10
*** bjz has joined #io15:14
jerprologic, yup, what's up?16:23
*** TheMonkey has joined #io17:42
prologicjer, oh hey!20:54
prologicjer, see backlog here:
jeri 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
jerthe 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 language20:58
jerthere'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 variable20:58
prologicjust kind of feels like you build an ast20:58
jerso for instance, instead of creating a whole number object20:58
prologicwhich is somewhat similar to the object model20:58
prologicsort of20:58
prologicbut it's now been days later since I said this20:58
jeryou might instead, tag it in such a way and embed the value in the untagged portion of the number20:58
prologicand I think I see the "slight" difference20:59
jerthus reducing your object footprint for numbers down to a simple mask operation20:59
prologicast is about parsing and representation20:59
prologicobject model is about runtime behavior20:59
jeryeah so object model wise20:59
jerreally depends on what you'er after20:59
jerbut typically you want to decouple these two things20:59
jerso 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 this21:00
jerif that's your VM which is the universe for the program, then cool, same logic applies21:00
prologicnext question/thoughts I had was around specializing bytecode insturctions21:01
prologicor building behaviors/functions on the internal object models that represent the oriignal source program21:01
prologicif you know what I mean21:01
prologicit seems to me that you could do it either way21:01
prologicbut the former would mean the compiler would have to treat certain patterns of message in a special way21:02
jerhonestly, 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 spirit21:03
jerio is notoriously hard to make efficient, and while compiling it into a sequence of instructions isn't hard, it's pointless.21:03
prologicsure :)21:03
jerwe actually had a message compiler at one point21:04
jerquag wrote one21:04
jerthis was in the pre-git days i think21:04
jerwe were still using darcs back then21:04
prologicbut you do get what I mean right?21:04
jerok, well it's not really the same structure though21:04
prologiccompile things like x = 1 to a special set of bytecode as opposed to just loading and pushing messages and performing evaluation at the interpreter level21:05
jerfor 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 frontend21:05
jeryou may even get a more compact bytecode representation by throwing out some info that's not useful in bytecodes that is required in the frontend21:05
jerthis 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 duplication21:06
jerbut it's not really intended to be that way21:06
prologicI think that's largely because Io21:06
prologicor language like it are so simple at their core really21:06
prologicfor 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 END21:07
prologicdoing lookups and activations on the object models themselves of the things we create from LOAD/EVAL21:08
jerhonestly, that's why i'd be more interested in building something ahead of time first21:08
jerthen worrying about interpreting it21:08
jerbecause it removes you from having to build the virtual hardware to run a custom ISA21:08
jerlet alone designing that ISA 21:08
jeri honestly think it easier to target native code, or an existing VM than to build your own21:09
jermy last VM was "wee" -- intended to be a very tiny runtime library to support an io21:09
jerand it worked off an entirely different type of runtime than io has21:10
jerthings like blocks were still real objects21:10
jerbut it was built for space optimization21:11
prologicI do see what you mean21:11
jeri used a lot of tagging for primitive objects21:11
jeras such, required allocations to be aligned21:11
jersimplified messages tremendously21:11
jerand an object's vtable was stored as a separate product type21:12
jerwhich was fixed at generation time21:12
jerto "open" it required special work, but was doable.21:12
prologichave to dash for the bus to work21:12
jerbut i did this so i could change the way lookup worked21:12
prologicbut thanks for the insight :)21:12
prologicvery helpful21:13
jerwith the idea of compiling to native code21:13
jerlater man21:13
*** gatesphere has joined #io21:16
*** gatesphere has quit IRC23:40
*** petr_ has joined #io23:50
*** petr has quit IRC23:52

Generated by 2.11.0 by Marius Gedminas - find it at!