public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* DSP-C in GCC
@ 2002-12-11 12:46 Jon Beniston
  2002-12-12  7:22 ` Jonah
  0 siblings, 1 reply; 2+ messages in thread
From: Jon Beniston @ 2002-12-11 12:46 UTC (permalink / raw)
  To: gcc

Hi,

I am currently prototyping an implementation of DSP-C like 
(http://www.dsp-c.org) extensions in GCC. If anyone is interested in 
this or would like to share some thoughts on how best to do this (I'm a 
GCC developer newbie) then please, let me know.

I'm planning on implementing a couple of new machine modes (SRmode -> 
for __fixed, SAmode -> for __accum, possibly SCmode -> for __circ) for 
the new datatypes. A collegue is suggesting that __fixed's should be 
mapped onto SImode, and then define a new set of operators. Any thoughts?

Cheers,
JonB



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: DSP-C in GCC
  2002-12-11 12:46 DSP-C in GCC Jon Beniston
@ 2002-12-12  7:22 ` Jonah
  0 siblings, 0 replies; 2+ messages in thread
From: Jonah @ 2002-12-12  7:22 UTC (permalink / raw)
  To: Jon Beniston; +Cc: gcc

I am certainly interested in any work in this direction. It is something on
my wish list to do.

My opinion is that it should definitely be new machine mode types (like
floating point is different). New operators don't make as much sense. For
example if you have:

(plus_fixed:SI (reg:SI) (reg:SI)) does that mean you are adding two ints
after converting or have they already been converted.

This however removes the ambiguity:
(plus:SR (fix:SR (reg:SI)) (fix:SR (reg:SI)). That means convert ints to
accum mode and add.

I think there is a advantage as doing as new modes for development time as
well. You may be able to get away with defining storage for the new modes
and, initially, not have to modify the front end too much.

A different approach that I have considered is creating a machine
description with a custom floating point type (like the c4x port) but have
the custom fp type be fixed point. Then once you have proved it that way
(i.e. with a machine description which has no real floating point types) you
can figure out how to allow a machine to have this custom type and a the
floating point type simultaneously by adding in the new front-end bits. The
nice thing about the c4x, if I recall correctly, is it has 40-bit types.

Along the circ buffer line I have not had as much thought. It is a trickier
problem. Most of the operations on fixed point types are the same/similar to
integer, but circular buffers means knowing more about the source code than
is currently easily available.

Please keep in touch.
Jonah

----- Original Message -----
From: "Jon Beniston" <jbeniston@siroyan.com>
To: <gcc@gcc.gnu.org>
Sent: Wednesday, December 11, 2002 5:09 PM
Subject: DSP-C in GCC


> Hi,
>
> I am currently prototyping an implementation of DSP-C like
> (http://www.dsp-c.org) extensions in GCC. If anyone is interested in
> this or would like to share some thoughts on how best to do this (I'm a
> GCC developer newbie) then please, let me know.
>
> I'm planning on implementing a couple of new machine modes (SRmode ->
> for __fixed, SAmode -> for __accum, possibly SCmode -> for __circ) for
> the new datatypes. A collegue is suggesting that __fixed's should be
> mapped onto SImode, and then define a new set of operators. Any thoughts?
>
> Cheers,
> JonB
>
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-12-12 14:43 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-11 12:46 DSP-C in GCC Jon Beniston
2002-12-12  7:22 ` Jonah

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).