In article <43178436.30408 / skynet.be>,
Bart Masschelein  <bart.masschelein / skynet.be> wrote:
>Hi guys,
>
>A few weeks ago, sbdy talked to me about Ruby, and Rails, and how 
>beautiful /sniff/ the language is. I took a look at it, and indeed, I 
>love the simplicity, or let me rephrase, the humanity of the language. 
>Definitely because I have a background in C/C++/Java, the first one 
>missing the ability of easy 'meta-languaging', the second one being 
>basically an OO hack of the first one (no offense meant), and the third 
>one, well, ok, close but no cigar. The company I work for builds tool 
>for optimizing algorithms (mainly multimedia applications), from the raw 
>description until the target platform. The problem is that all those 
>tools only accept C. I believe that Ruby might be a better choice for 
>this, definitely in the early stages of the optimization, because you 
>can analyse your program from a layer above it, which according to Godel 
>is sometimes necessary. So in my off-duty time, I'm building some 
>examples to convince them. But alas, I already now their first question, 
>and have no answer to it, and that's why I phrase it here: What if the 
>code is optimized, how do you go to a platform with specific processors 
>on them? For C, many are out there. So here is my question to you guys:
>
>1) Are there any efforts, or is it at all possible, to write a Ruby 
>compiler, for lets say a TI/C64 DSP processor?

Not likely.  If we had a compiler that would target a DSP we would also 
have a compiler that would target x86, no?

Might I suggest a different approach:
A few weeks back I was doing a lot of work with video processing using a 
Matrox card and their Genesis API.  A lot like doing DSP, actually.  
Their C API has all sorts of image processing functions.  However, it's 
rather klunky - I would say it's akin to programming in assembly in C: 
Allocate a buffer then load the buffer with data then perform some 
transformation on the buffer... very tedious, very easy to make mistakes 
which are difficult to debug.  So then I had an idea: why 
not write a DSL (domain specific langauge) using Ruby that would allow me 
to bypass some of the tedium.  The DSL would be used to describe the 
dataflow.  That description would then be translated to the Matrox API (C 
code).

So for example I could do things like this (to the best of my memory):

require 'gencode'
include GenMatrox
Description.new {
  Task {
    cam1 = Camera 
    b1 = Buffer(640,480) #allocate an 640X480 video processing buffer
    halfsize = Buffer(320,240)
    b1 << cam1  #capture camera output in b1
    halfsize << b1.zoom(0.5) #zoom in 
  }
}.to_c

When that code was run it would generate about 40 lines of C code 
including all the variable declarations which could then be compiled.  

So perhaps you could create a DSL for specifying the algorithm you want 
and generate C code targetted to the DSP.  The DSL would then generate 
the C code for you.  Of course this is only a win if you can create the DSL 
in such a way that it is a much higher-level description than the C would be 
(as the example above where about 10 line of Ruby became about 40 lines of C)

>
>2) If the answer to the first question is negative, how good is the 
>(http://easter.kuee.kyoto-u.ac.jp/~hiwada/ruby/rb2c/) ruby to C 
>convertor? I did not have a look at it, and wont have time probably in 
>the near future, but can it handle any Ruby code? That would be amazing, 
>as there not even really good C++ -> C convertors. Does it handle 'your 
>typical Ruby' constructions? I would already be happy if it can handle 
>C-alike code mixed with classes.

A much more recent (and maintained) Ruby to C converter can be found 
here:
http://rubyforge.org/projects/ruby2c/

Anything like this will have limitations (a lot of dynamic things like 
eval can't be converted) but maybe they're not an issue for what you're 
doing?

>
>I know, an obvious answer would be, try it yourself, but if sbdy can 
>shed a light, that would be a big motivation/demotivation. One answer I 
>can imagine is that Ruby is not targeted for such low-level stuff.
>

Maybe you can give us a little more info about what you're doing?  I 
would think about the DSL approach I described above - it might be a fit 
for what you're doing.  I know similar 
approaches have been used to define assemblers in Ruby and assemblers are 
pretty low-level.

Phil