On Sun, Jun 06, 2004 at 10:55:06PM -0600, Rodolfo J. Paiz wrote:
> At 09:34 6/6/2004, Jeff Vian wrote:
> >Please explain what compiler / tricks need to be used if gcc cannot be
> >used.
>
> I think his meaning was that gcc would not "just work" as in would not work
> automatically, out-of-the-box, or without adjustments... pick your slang
> expression. I don't think he meant that gcc would "just not work," which is
> an entirely different meaning.
Consider the mmx class of instructions that Intel introduced.
What "C" code causes these instructions to be generated by gcc.
See ..../arch/i386/lib/mmx.c where in line assembly is used. For the
class of SIMD and other complex instructions that I expect exist in
the interesting GFX engines other abstractions beyond those addressed
by MMX are involved. I have not disassembled all of Linux to check
but these are rare instructions and I believe that they are all
generated by hand crafted assembler directives. If mmx instructions
are unused by gcc then the interesting GFX engine functions would likely
be unmapped to "C" code structures as well.
Yes the 'gnu' compiler and assembler could be modified but these are
not off the shelf general purpose processors. There are no flags for
these engines in the existing gcc code base. Think Xilinx Virtex-II
Pro, 29K bit slice or perhaps the classic Motorola MC14500B if you
want to research and think about these GFX processors (MC14500B is key).
The assembler has to be built for each custom engine, then the code
generation templates for the 'C' compiler. Then because the
abstractions in the 'C' language do not express the transformations
that are interesting to 3D graphics, hand coded blocks and or
special compiler (language) extensions are needed. There is
also no standard ABI for these custom engines.
Not only is there a lack of support for 3D graphics abstractions in
"C" expect also a complementary lack of support for "C" in these
special purpose GFX/vector engines.
One of the problems with complex instruction set processors (GFX
engines are complex) is that compiler writers often ignore the full
instruction set because the abstractions of the language do not match.
Hmm time for me to dust off "Computer Architecture a Quantitative
Approach", J.L. Hennessy and D. A. Patterson, 2nd Edition, 1996.
These are not frame buffers with 'common' processors glued to them.
Do not get me wrong I would love it if all these drivers were full
open source. But for me this takes second place to the question
of vendor support.
Vendor support is my requirement!
Full open source and open hardware documentation would be wonderful.
In the past I have ranted on a specific scanner given to me by my
brother. He upgraded his WindowZ box and the 'old' scanner was not
supported on the new WindowZ OS (and not on Linux). This scanner
vendor will never see a penny from me. Because they fail to support
their product on anything. Had they supported my brother in his
upgrade or opened up the hardware details so I could use it on Linux I
would not say a cross word. So, beware of "OneTouch" and any other
vendor that has a support matrix that looks like Swiss cheese.
Again,
Do not get me wrong I would love it if all drivers were full open
source and hardware fully documented!
Vendor support is my single requirement!
drivers please
if no drivers then documentation so we can build our own drivers.
drivers + documentation -- best of both worlds.
When a vendor gets weary of updating their drivers... publish the
documentation then move on. I would love to see hardware vendor
support matrix tables use three codes: (ds), (dd) or (os).
Where "ds" indicates data sheet for device driver writers published.
(dd) device driver binary, and (os) for open source driver.
I would kindly at vendors that had all three (ds+dd+os).
Hello sound card and modem vendors..... Three simple options ds, dd, os.
--
T o m M i t c h e l l
/dev/null the ultimate in secure storage.
