re-sent due to it being classified as spam by the gnu.org ml server :)
----- Forwarded message from Luke Kenneth Casson Leighton <[EMAIL PROTECTED]>
-----
From: Luke Kenneth Casson Leighton <[EMAIL PROTECTED]>
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>
--
