public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nick Ing-Simmons <nik@tiuk.ti.com>
To: lars@nocrew.org
Cc: gcc@gcc.gnu.org, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>,
	meissner@cygnus.com, Mark Mitchell <mark@codesourcery.com>,
	Joe Buck    <jbuck@racerx.synopsys.com>
Subject: Re: PDP10 support
Date: Thu, 14 Sep 2000 07:47:00 -0000	[thread overview]
Message-ID: <200009141445.PAA01668@mikado.tiuk.ti.com> (raw)
In-Reply-To: <85n1hbfnq5.fsf@junk.nocrew.org>

Lars Brinkhoff <lars@nocrew.org> writes:
>
>It would also be interesting to hear from the DSP folks.

Okay here is a _personal_ view as someone that has tried to ports 
to various TI DSPs:

Weird addresses would have been useful for one of the ports
(actually thing was more of a micro-controller than a DSP).

Older C2X DSPs, and modern C5X which are backward compatible are 
16-bit words only. As such addressing bytes was just not possible - 
packing bytes means reading 16 bits and/shift/or and write 16 bits.

C3X/C4X are basically 32-bit with "some" support for messing with bytes
they also have non-IEEE 40-bit float.

C6X is byte addressed. 
C8X is byte addressed.

Most of the problems with DSPs were not the format of the addressing,
but:

 -  opcode squeezing which meant that which set of index registers
    you could use depended on choice of base registers etc.
    Reload has no support for such stuff, so you end up using a 
    subset of registers.
 -  Register allocation - GCC likes to keep a pseudo in one hard register,
    but if you multiply it and then use as an index it has to move.
    So you need to split into multiple pseudos then stop GCC collapsing
    them back into one.
 -  the lack of hardware interlocks (exposed pipeline) meaning need 
    to insert NOPs for loads and other multi-cycle ops - as well as branches. 
 -  VLIW scheduling. (Super scalar without harware interlocks.)
    Also register allocation which depends on which "unit" operation
    is scheduled for.  
 -  Fussy details like HI*HI => SI multiply is highly optimal 
    so shift schemes need to be disabled - except when used 
    for address generation.
 -  Figuring out what RTL "combine" would come up with for 
    expressions that mapped on to DSPish things like MPY+ADD+SHIFT 
    so that insn patterns that matched could be written



-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

  reply	other threads:[~2000-09-14  7:47 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-09 12:33 m68k MacOS target support? Michael Sokolov
2000-09-11 20:47 ` Stan Shebs
2000-09-11 20:56   ` Michael Meissner
2000-09-11 21:33     ` Mark Mitchell
2000-09-12  0:02       ` lars brinkhoff
2000-09-12  0:15         ` Mark Mitchell
2000-09-12  3:26           ` lars brinkhoff
2000-09-12  7:23             ` Mark Mitchell
2000-09-12 11:16           ` Joe Buck
2000-09-12 11:22             ` Bernd Schmidt
2000-09-12 20:11               ` Mark Mitchell
2000-09-12 13:59             ` Stan Shebs
2000-09-12 17:55               ` Richard Henderson
2000-09-12 19:12                 ` Stan Shebs
2000-09-12 22:44                 ` "Dead" Ports (was: m68k MacOS target support?) Gerald Pfeifer
2000-09-13  9:26                   ` Jeffrey A Law
2000-09-13  9:33                     ` Bernd Schmidt
2000-09-13 11:40                       ` Stan Shebs
2000-09-13  9:57                     ` Bruce Korb
2000-09-13  3:17                 ` m68k MacOS target support? Joseph S. Myers
2000-09-12 11:48           ` Toon Moene
2000-09-12  7:32         ` Jeffrey A Law
2000-09-12 11:11         ` PDP10 support (was Re: m68k MacOS target support?) Joe Buck
2000-09-13 14:51           ` PDP10 support Gerald Pfeifer
2000-09-14  0:15             ` lars brinkhoff
2000-09-14  7:47               ` Nick Ing-Simmons [this message]
2000-09-12  0:03       ` m68k MacOS target support? lars brinkhoff
2000-09-12  9:52   ` David Huggins-Daines

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200009141445.PAA01668@mikado.tiuk.ti.com \
    --to=nik@tiuk.ti.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jbuck@racerx.synopsys.com \
    --cc=lars@nocrew.org \
    --cc=mark@codesourcery.com \
    --cc=meissner@cygnus.com \
    --cc=pfeifer@dbai.tuwien.ac.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).