[A86] Re: SDCC v2.3.0
[Prev][Next][Index][Thread]
[A86] Re: SDCC v2.3.0
> You told lately something about 'vectors' that GCC doesn't (but should)
> use. Can you explain a bit further? In the iCode dump of SDCC I see the
> term 'bitVector', could that be the same you were talking about?
No, a vectorizing compiler is in no way similiar to this. Compilers for
IA32 cpu's that have MMX and similiar instructions for performing multiple
operations on different data at the same time. This is very useful for code
that manipulates vectors, in the sense of math / physics / graphics, because
multiple calculations can be done at once. All points of a vector can be
calculated at the same time, with the code written in standard C, rather
than resorting to assembly language. Games are an obvious area where this
is necessary, but other types multimedia benefit.
See www.codeplay.com for an example of such a compiler. They are targetting
game developers, but according to many people on Slashdot, it is useful for
the scientific community as well. The Pentium 4's instructions operate on
double precision floats, so it is much more useful for scientific work.
Earlier processors only work with single precision floats, which is why they
are targetting them. Their benchmarks are very impressive.
> Uhm, I didn't mean standard stuff (text I/O, string.h, etc.), but graphics
> (routines) and the such. At the moment you can make a tremendously
> beautiful C compiled program that can't output anything (graphics text
> whatever), not usefull I think...
>
> You could off coarse define some ROM routines as 'external' (like _puts),
> SDCC passes the first argument via HL.
Outputing text is not a problem. There would be wrappers for rom calls that
would merely define the calling conventions. The function call overhead
would be non existant, as compiler would essentially inline the function
call.
Graphics routines would be written in assembly, of course. What do you need
besides a putsprite routine? Graphics code is fun to write and optimize in
assembly. Boring stuff like control structures should be left up to the
compiler.
> Okay some script (batch, whatever) that you can input the name, icon-data
> (going to be difficult), and shell type. It will first assemble the right
> crt0 with the input, copy the crt0.o file to the right dir and start the
> compiler?
There's this wonderful thing called make that was designed for this... :)
> I think that's quite inconveniant in comparsion to the z88dk where you can
> do (in your c file):
>
> #pragma output string name Description
> #pragma output data icon 0xFF, 0x02,...
>
> Which will let the compiler ouput a file (zcc_opt.def) which get's picked
> up by the crt0 file. So you don't get something like:
>
> $>SDCC tetris.c -mz80 --name="Nibbles!!!"
>
> Because you state that in the .c file itself.
I don't see how it is any different to write it in the Makefile than to
write it in the C file. You'd have a skeleton Makefile where you just fill
in the values. If it's that big of a deal, write a custom preprocessor to
strip them out or something. That kind of stuff belongs in the Makefile or
elsewhere, not with the code. I'm glad Assembly Studio 8x 4.0 removed
.plugin and puts it in the project files, where it belongs.
References: