🚀 go-pugleaf

steve@nuchat.sccsi.com (Steve Nuchia) writes:

>In article <johnr.719787436@ee.uts.EDU.AU> johnr@ee.uts.edu.au (John Reekie) writes:
>>I think it's partly a problem with the language. For example,
>>C has no way of representing modulo addressing. If I have
>>a circular buffer amd I want to write one sample into it, then I
>>can either i) do it in C and manually test and wrap the pointer,
>>or ii) call an assmebler function and have it do teh write
>>real efficiently --- apart from the call, that is! If the

>I have been working with the GNU C compiler on a 486 host.  I have
>found that the _asm_ directive support in that compiler, combined
>with the inline function directive, provide very good access to
>special architectural features without having to step outside the
>C language too far and without subroutine linkage overhead.

[Further explanation deleted.]

>In summary, I think there is a middle ground left out of the
>conclusion quoted above.  It is possible, at least with GCC,
>to efficiently and safely invoke specialized instruction sequences.
>With some experince and good judgement it can even be reasonably
>clean.

Yes, I agree that I hadn't considered (i.e. wasn't aware
of!) the asm features of gcc, which makes my argument
somewhat limp. 

What do you think about the idea of having the compiler
"understand" certain objects, so it can generate efficient
inline assembler code  for calls to those objects? If the
compiler doesn't understand some object, then it would
just compile the textual class definition. In say G++,
could one define say a modulo buffer class, and then define
a particular version of that class for a particular machine
that will generate _inline_ assembler for calls to it?
The idea is that your code is now portable -- the assembler
templates are hidden inside the modulo buffer class, and if
you port to a new device, you can either use the standard
class, or (when you need the speed) write assembler
templates for the new device. Will this work?

Regards

John Reekie