Re: Hot Topics in languages & question on TWIG

--In reference to answers to Mr. Gilliam's question about
--"Hot Topics" in languages (91-11-030):


It's not nice to be harsh on graduate students who are searching for a
thesis topic. My case: I have some ideas, but the architecture people
here aren't into DSP's. They don't do much with computer music and I
don't know all the faculty. I know what I like to study, but I don't know
what I CAN study given the money and knowledge here.


--And in reference to his question:


Here's an idea from comp.dsp and the signal processing freaks'
frustration: C compilers for DSPs barely work-- they don't take advantage
of signal processing-related architectural features in the chips, such as:


          Hardware do-loops :
Limited nesting level (7 on DSP56001 from Motorola), makes this
optimization a hard problem


          Bit-reversed addressing :
Useful for the butterfly in a Fast Fourier Transform, but hard to
detect that it's appropriate.


          Multiple functional units :
DSP56001 has address "ALU" that works independently of integer core,
allowing two loads in parallel with ALU ops. Scheduling is a hard problem
(not limited to DSP chips).


The solution that some people are moving to in comp.dsp is new High Level
Languages that have special signal-processing related statements.


Another approach, taken by the IRCAM computer music group in France, is to
forget DSPs and use VERY fast general purpose CPUs for signal processing.
They use Intel's 860, which also lets them do floating point instead of
fixed point- no rounding needed.


My idea is to forget textual languages altogether and use visual
languages. Visual languages (also dataflow languages- I'm just starting
to read in the field, so I'm not sure of all the lingo) work with
"operator blocks" taking input, doing their thing and producing output. A
logic schematic is a visual language, especially when you have a simulator
and you can draw the blocks with a mouse, then animate the states of the
lines in and out of the gates, flip-flops, etc.


In signal processing, you can take a symbolic representation of a digital
filter, usually a Z-transform, and pretty easily turn it into a collection
of:


unit delays - delay input by one sample
amplifiers - multiply input by a constant
summers - add up their inputs




People seem to be moving this way, but quietly. IRCAM's system, which
uses a NeXT cube as a host, has a language developed at Opcode (for the
Mac originally) called MAX. VPL, the virtual reality people, use visual
programming for creating virtual worlds. Jaron Lanier claims they started
VPL to develop programming environments IN virtual reality- visual
programming in 3-D! National Instruments' LabView, for controlling lab
experiments with a Macintosh, also uses a form of visual programming.


I've found NOTHING on how this stuff is implemented. "Compilation" and
code generation for visual programs seems to be either a big secret or a
black art. Academic contributions (read: not proprietary) are certainly
needed.


--Question:
has anyone worked with Twig- the code generator generator described in
Aho, Ganapathi & Tjiang's paper _Code Generation Using Tree Matching and
Dynamic Programming_, AT&T Bell Labs, 1986? I gave a presentation on the
paper a couple of days ago & it dawned on my tonight that I have a use for
it. I found ML-Twig, which uses ML instead of C on anonymous FTP site:
cs.tut.fi /pub/src/languages/sml/lib


I suppose I can get the rest of ML for free, but I'd rather work in C. Is
Twig locked up, or FTP-available? Any experiences using it? Since it
doesn't do register allocation, what method did you use- Chaitan or an
improvement?


I love to spend too much time answering mail on these topics. I'm:


Reply-To: Morgan Woodson, Computer Engineering grad. student at
            University of California, Santa Cruz.
[In reply to the second question, there have been inquiries about twig
before, and it is available with restrictions, see message 91-05-009. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.