[ruby-core:23709] Re: Standard Ruby bytecode

Eero and Rick,

Thank you for taking the time to explain this. You guys have of course 
thought this through and I see your points.

I understand that I probably approached this in a naive way. I came 
across projects like the Unladen Swallow, with their LLVM based VM 
implementation, MacRuby's new direction, which you mentioned as well, 
etc and was led to believe that LLVM could also make for a suitable 
bytecode/bitcode format for interpreted languages, such as Ruby.

The benefits I had in mind, were related to the use of LLVM's IR, which 
is probably off topic. More specifically, I was 'connecting dots' 
between the future directions of a completely different project, 
involving a synergistic GPU/CPU driver framework, named Gallium3D and 
the prospect of an LLVM based VM. These guys are planing to ditch their 
current custom IR in favour of LLVM's IR, thus tapping into those 
optimisation stages LLVM provides. Long story sort, I was envisioning 
situation where you could run your interpreted language programs on your 
GPU, kind of 'natively' (whatever that means), a GPGPU 'nirvana' if you 
like. By the way, this is not simply a pipe-dream of mine. The Gallium3D 
devs do see this as a potential. But as I said, it's probably off topic.


regards,
Ioannis




Eero Saynatkari wrote:
> Excerpts from Ioannis Nousias's message of Thu Jun 04 12:11:06 +0300 2009:
>   
>> I came across this post:
>>
>> http://stackoverflow.com/questions/884186/can-ruby-php-or-perl-create-a-pre-comp
>> iled-file-for-the-code-like-python/949163#949163
>>
>> a question that I was interested for an answer as well. According to 
>> J旦rg W Mittag, there is no standardised bytecode at the moment, with 
>> every VM implementation having its own, with a possibility of adopting 
>> YARV's bytecode as a standard in the future.
>>     
>
> The question seems to be about a /non-portable/ bytecode
> file? This is naturally quite achievable and Jorg does
> a good job of answering it in the linked thread. Rubinius
> does compile all .rb files to .rbcs and will use the latter
> if the original (and the compiler) is unchanged.
>
> There is a separate question of whether it is possible and
> make sense to define a *portable* bytecode format so that
> a bytecode dump file could be loaded by any interpreter. I
> personally do not see any benefits (slightly smaller file
> size for transfer? Extremely weak obfuscation?) outweighing
> the disadvantages (the implementations cannot produce the
> kind of bytecode they view to be the best possible for the
> platform it is intended to run on.) I am sure that I may
> be overlooking some benefit, so please do correct me in
> that case.
>
> The second concern, of course, is that the move is now to-
> ward object code (native code), no longer bytecode, which
> brings us to the second part:
>
>   
>> my question to the ruby developer community is: has anyone considered 
>> using LLVM's [1] bytecode for this purpose. I don't know how applicable 
>> it is, but I would expect certain advantages using a well establish 
>> format, instead of yet-another-custom-bytecode, with the potential of 
>> taping into LLVM's resources.
>>     
>
> In short, it is not possible to "use LLVM's bytecode" for
> this, because it is not representative of a Ruby program.
> Basically, that question is the same as "is it possible to
> use ASM to represent a compiled Ruby file?"
>
> (By the by, LLVM uses the term "bitcode" -- not a nag, it
> will just be easier to search for those terms)
>
> It is certainly possible to actually use LLVM and thereby
> possibly its bitcode which is what Rubinius is doing (as
> is MacRuby?) If such bitcode were dumped, though, it would
> still be highly dependent on the target VM, unless again
> a specific effort were made to to translate it to a generic
> representation -- necessitating, almost certainly, another
> translation pass when loading the code back in to get the
> benefit of the VM architecture in question) which leaves
> us back at the earlier point.
>
> And, as intimated before, it is actually possible -- though
> how useful and feasible I am not sure -- to dump the /object
> code/ representation of JIT (or AOT) compiled Ruby for the
> implementations that support that functionality (essentially
> similar to the .o files a C compiler produces, though with
> some .so-ish semantics.) I would certainly not go so far as
> to say that this makes bitcode or .rbc files obsolete in the
> near future, but it is another thing to consider.
>
> (Disclaimer, just in case: I am working on Rubinius and so
> naturally biased in its direction.)
>
>
> Regards,
>         Eero
>
> --
> Magic is insufficiently advanced technology.
>
>
>
>
>
>
>   


-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.