public inbox for cgen@sourceware.org
 help / color / mirror / Atom feed
From: "Frank Ch. Eigler" <fche@redhat.com>
To: cgen@sources.redhat.com
Subject: generalizing the delay rtx function
Date: Thu, 08 Mar 2001 13:01:00 -0000	[thread overview]
Message-ID: <20010308160106.A28162@redhat.com> (raw)

Hi -

As you may be aware, the delay rtx function is used, despite its
work-in-progress designation, to model delayed branches in
constructs like
	(delay 1
	   (set pc (add pc 42)))
The DELAY-SLOT insn attribute is inferred from this for use by
simulator mainlines.  That's the extent of the effect of the delay
rtx.

In order to model architectures with exposed pipelines (i.e., no
or limited pipeline interlocks), and related effects like delayed
loads, I'd like to take it beyond this, by coupling it to the
parallel-write mechanism.

As you might be aware, ports that have VLIW features tend to use
the "parallel-write" mechanism in their semantic blocks in order
to queue updates to registers/memory? until after all concurrently
executed instructions have been processed.  This lets multiple
reader instructions execute together with a writer instruction,
without detailed worry about the evaluation sequence.

Anyway, how about a scheme such as this:

- Provide a clear definition for the DELAY rtx:
  The numeric argument is the number of instruction cycles
  after the current one, at which the enclosed set expressions
  take effect.
- Restrict the use of the DELAY rtx to only contain SET expressions
  to hardware/memory registers.  Forbid other calculations.
- Possibly, force use of (DELAY 0 ....) to express VLIW concurrency,
  at least in new ports.
- Infer "parallel-write?" (or a new equivalent) from the presence of
  DELAY rtxs.
- Eliminate special treatment of PC by fitting delayed branches into
  this model.

Then, the generated simulator code would be changed, so that:

- Semantic functions, instead of taking a single parexec structure
  pointer (for write queueing), take an array of them.  Within
  (DELAY <N> RTX*) blocks, define OPRND to point to the appropriate
  elements in the parexec array.
- The insn evaluation loop would keep an array of parexec structs
  as a rotating buffer, always running the writeback code on the first
  one, then rotating the set, then passing it to the next insn.  cgen
  could compute the maximum index needed.

This way, code like
	(set reg1 1)
	(delay 0 (set reg1 3))
	(delay 1 (set reg2 5))
	(delay 2 (set reg1 6))
would each be well-defined and useful.

An alternate cgen syntax possibility is to introduce a
	(delayed-set N lvalue rvalue)
rtx.

Any advice?


- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6p/MSVZbdDOm/ZT0RAhEUAJ0bwN0RZp+xVHRPYAqGSVyAAyBG4gCcCWDM
cYY/X5f0qbjpafcqdKj1FKw=
=3H6j
-----END PGP SIGNATURE-----

             reply	other threads:[~2001-03-08 13:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-08 13:01 Frank Ch. Eigler [this message]
2001-03-12 20:04 ` Ben Elliston
2001-03-12 20:33 ` Doug Evans
2001-03-13 23:40 ` matthew green
2001-03-14  5:05   ` Frank Ch. Eigler
2001-03-14 16:43     ` matthew green
2001-03-14 16:55       ` Frank Ch. Eigler

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=20010308160106.A28162@redhat.com \
    --to=fche@redhat.com \
    --cc=cgen@sources.redhat.com \
    /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).