[lkcl@lkcl.net: has gcc been reworked so that code/templates can be "outsourced" e.g. to perl yet?]

[Luke Kenneth Casson Leighton <lkcl at lkcl dot net>]

re-sent due to it being classified as spam by the gnu.org ml server :)

----- Forwarded message from Luke Kenneth Casson Leighton <lkcl@lkcl.net> -----

From: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
To: gcc@gcc.gnu.org
Subject: has gcc been reworked so that code/templates can be "outsourced" e.g. to perl yet?

hi,

over two years ago i discussed some matters with you regarding
"outsourcing" of code to external programs.

a redesign of gcc's parser from its single-ended
yacc-based Thing to what i understood to be a double-ended
hit-it-from-both-ends-of-the-source-code-file approach.

and that this would alleviate the need for a separate macro
pre-parser apart from anything else.


there is a company called aspex technology who have a massively
parallel SIMD array co-processor, with which they communicate
via a PCI bus, by placing assembly code instructions into a
memory-mapped FIFO instruction queue.

they have a proprietary tool-chain - the key to it is that it
runs as a macro pre-parsing stage, converting anything with
"aop { .... my proprietary assembly code instructions .... }"
into this:

pci_bus_device->fifo_mem_addr[0] = 0x9999999;
pci_bus_device->fifo_mem_addr[1] = 0x8888888;
pci_bus_device->fifo_mem_addr[2] = 0x8888800 | x;

etc. where x is a local or global c variable which was referenced
[legitimately!] somewhere in the "aop { ... }" assembly codeblock.

at first sight, this appears to be _great_.

... but, when you involve c++ templates, it shows up to be total crap.

there is no means to out-source from the templated code once the
template has been "instantiated" with its "real" variables (i don't know
the terminology you use - my apologies) rather than the "templated
names".

at the time i last looked at this, i was giving
serious consideration to writing a tree "regenerator" /
"pretty-printer", regenerating code fragments, calling a system
call with the proprietary tool-chain on the "aop { ..... }" bit
of code, then RERUNNING the gcc parser on the resultant c-code,
and substituting the resultant parsed tree of symbols _back_ into place.

as you might imagine, i ran into difficulties with variable scope :)


now - why am i describing this to you?

well, the key reason is this:

Aspex's 4096 ALU "F" architecture and their planned 65536 ALU
"G" architecture (yes, that's right, 65536 2-bit pipelined SIMD
processors, running at 400Mhz - you do the math) is NOT the
only architecture that can benefit from the above techniques.

there are OTHER SIMD / vector processor units out there that
are _crying out_ for this "outsourcing" technique, and Aspex's ASP is
only at the extreme end of that.

MMX instruction set.

Sony Playstation vector unit.

programming parallel/vector coprocessors is sick and requires
insane levels of expertise that make it difficult for the
speed benefits of these processors to be realised: except for
nutcases like myself, the learning curve drastically offsets
the benefits to the point where you (sony, intel, aspex)
might as well not bother.

that can _all_ change if gcc is capable of "outsourcing" template
post-processed code fragments and re-parsing them ** IN SCOPE **.

why?

well, because of the valarray c++ templates, that's why.

imagine being able to do a hardware-accelerated version of
the valarray STL templates, where instead of utilising 65536
add instructions, you end up with an ASP performing the same
65536 add instructions -  in a few microseconds.

and it's exactly the same c++ code, but recompiled with a
different -Iinclude directory and a library.

same goes for MMX instructions - same goes for Sony PS vector unit.

same goes for any SIMD vector unit.

l.

--
--
<a href="http://lkcl.net";>http://lkcl.net</a>
--

----- End forwarded message -----

-- 
--
<a href="http://lkcl.net";>http://lkcl.net</a>
--