From: ptkwt@... (Phil Tomson)
Date: 2005-09-05T15:01:27+09:00
Subject: Re: Ruby compilers (for DSP processors and alike)

In article <431AD05D.4050603@skynet.be>,
Bart Masschelein  <bart.masschelein@skynet.be> wrote:
>
>>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 what is such a DSL exactly then? In your case, it is a Ruby piece of 
>code which is translated into C, which uses the Matrox API? 

It's not translated per se, but running that Ruby code causes the C code 
to be generated - it's more correct to think of it as a code generator 
than a code translator, I think (I'm not doing any parsing, for example)

>Or is there 
>more behind the piece of code you give here, which is part of the DSL, 
>like a convertor to replace a specific Ruby line of code into specific C 
>lines of code?

Kind of.  Actually, each Ruby line of code might generate several lines 
of C code. 

For example, if I declare a Buffer in my Ruby-DSL like so:

  b1= Buffer(640,480)

In C we first need to declare the buffer somewhere toward the top:
  long b1;  //declaration

Then we need to actually set up the buffer later on using the matrox API:
  imCreateBuffer(Thread, 640,480, 0L, 0L, &b1); //allocation

Then later on at the end of the program we need to de-allocate that 
buffer:
  imBufFree(Thread,b1,0L,0L); //de-allocation

So that one line of Ruby generates all three lines of C in the right 
place in the C code (I break it up into three pieces: declaration, 
allocation, de-allocation - actually some actions required a 4th step 
between allocation and de-allocation, now I forget what that was, but 
you get the idea)

>
>>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
>>
>>  
>>
>>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.
>>  
>>
>Where could I find more information on this issues? It would be 
>interested to have a look at these.

From your other response (that I also responded to this evening) I'm not 
sure this approach (a DSL that generates C) would necessarily work in 
your case, but perhaps it would.

The idea is that if you could somehow describe your algorithm using this 
DSL you could then execute the ruby program that your DSL describes and 
generate C code.  For example, you mentioned array accesses:

Defining the array in Ruby:
  array = Array.new(8)

Would have to create the following in C:

  int array[8];

Then later on when you access the array:

  array[x]= y #in Ruby

generates:
  array[x]=y; //in C

Actually, those are prettymuch identical.

YOu could do this by redefining the various Array methods you're using so 
that they spit out some corresponding C code when they are run (remember 
to alias the original Array methods so that you can call them after 
generating the C code - that way your DSL can be executable to actually 
run the algorithm as well as generating C code if that's what you want)
Oh, and you probably would need to define some class that pairs a value 
with a name, so that the 'y' above would have been defined like:
  y = MyVar.new(:y) #need some way to know the name of var y
(yes, it seems a bit redundant, but there's no way to know the name of 
the variable 'y' otherwise when you're generating the C code).

But, based on what you said in your other response, I'm not entirely sure 
that this approach buys you much.  Perhaps if you need to generate two 
different types of output (C and VHDL for example) it might save some 
effort to use a DSL approach because you could create to_C and to_VHDL 
methods so you would be able to generate either from the same input.

Phil