9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Charles Forsyth <charles.forsyth@gmail.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] FP register usage in Plan9 assembler
Date: Thu,  4 Feb 2016 15:07:38 +0000	[thread overview]
Message-ID: <CAOw7k5i2c6Rdgx=x3EdEVuKrOObmjjmqjD3RiEOVAvj=kmUh5g@mail.gmail.com> (raw)
In-Reply-To: <A8CE1CB7-AA9C-4D15-9E04-34B5675581D9@me.com>

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

On 4 February 2016 at 12:24, Brantley Coile <brantleycoile@me.com> wrote:

> Which plan 9 assembler uses right to left argument assignments, or compare
> argument order


For example, the ARM's MCR and MRC instructions are unchanged from the
manufacturer's order.
Partly that's because the "instructions" are really just encoding a set of
fields that happen to include one or two processor
registers that might or might not be accessed. Those are the only ones I
can think of off-hand, but there might be others.
On PowerPC, even LWAR ("load") and STWCCC keep to the data-flow order,
though.

CMP on some RISC architectures keeps the order of the underlying
subtract-discarding-result that it represents.
Perhaps they all do it. When I've done a new architecture, I try to keep
the feel of similar architectures (RISC or CISC).

The typed registers vs typed instructions was originally easy: integer
operations used the same register names (eg, typically Rn, but also AX, DX,
...) and the instruction was byte/word/long, instead of encoding lengths as
in %ax vs %eax (but of course x86 has to have AL, AH, etc for compatibility
with 8086). Floating point registers had their own name, but the
instructions still had a type, so it was ADDF or FADD not
just ADD F0, ... . Then vectors and logical registers nested inside
physical ones or aliasing them appeared, and now even the RISCs
have instructions with a result type but possibly different types for each
operand.

Note though that although the terms "assembler" and "loader" are used,
the whole scheme starts with the use of an abstract syntax of a given
architecture for use by the compilers.
The assembler is just a readable version of that abstract syntax, that's
vaguely like a conventional assembler
including the funky upper case names. It could be S-expressions.

I still quite like the distribution of work, for the reasons Aram just gave.
Latterly, I've been making the things a little smaller and perhaps simpler,
by continuing some changes that
Russ made (eg, pgen.c pswt.c) to reduce the amount of almost identical code
that's replicated across the suites.

[-- Attachment #2: Type: text/html, Size: 3070 bytes --]

  parent reply	other threads:[~2016-02-04 15:07 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-01 16:47 Giacomo Tesio
2016-02-01 22:38 ` Charles Forsyth
2016-02-01 22:44   ` Charles Forsyth
2016-02-01 22:48 ` cinap_lenrek
2016-02-01 23:34   ` Giacomo Tesio
2016-02-02  0:36     ` Charles Forsyth
2016-02-02  0:58       ` Giacomo Tesio
2016-02-02 12:39         ` Aram Hăvărneanu
2016-02-02 16:42 ` Steven Stallion
2016-02-02 17:16   ` lucio
2016-02-03 15:24   ` erik quanstrom
2016-02-03 15:51     ` Steven Stallion
2016-02-03 16:36       ` erik quanstrom
2016-02-04 10:08     ` Aram Hăvărneanu
2016-02-04 12:04       ` lucio
2016-02-04 15:58         ` Ryan Gonzalez
2016-02-04 16:09           ` lucio
2016-02-04 18:06             ` Ryan Gonzalez
2016-02-04 18:14               ` balaji
2016-02-04 18:28             ` Ryan Gonzalez
2016-02-04 19:31           ` Skip Tavakkolian
2016-02-04 12:24       ` Brantley Coile
2016-02-04 12:53         ` lucio
2016-02-04 14:57           ` erik quanstrom
2016-02-04 14:05         ` Aram Hăvărneanu
2016-02-04 14:10           ` Aram Hăvărneanu
2016-02-04 14:30             ` Aram Hăvărneanu
2016-02-04 15:07         ` Charles Forsyth [this message]
2016-02-04 15:16           ` erik quanstrom
2016-02-04 15:11         ` erik quanstrom
2016-02-04 15:22           ` erik quanstrom
2016-02-04 15:26             ` Charles Forsyth
2016-02-04 20:34               ` erik quanstrom

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='CAOw7k5i2c6Rdgx=x3EdEVuKrOObmjjmqjD3RiEOVAvj=kmUh5g@mail.gmail.com' \
    --to=charles.forsyth@gmail.com \
    --cc=9fans@9fans.net \
    /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 NNTP newsgroup(s).