From: Alan Modra <alan@spri.levels.unisa.edu.au>
To: ian@cygnus.com (Ian Lance Taylor)
Cc: gas2@cygnus.com, martynas@nm3.ktu.lt, hjl@lucon.org
Subject: Re: A PREFIX_SEPARATOR bug in binutils 2.9
Date: Tue, 21 Apr 1998 17:45:00 -0000 [thread overview]
Message-ID: <199804220045.KAA02314@mullet.Levels.UniSA.Edu.Au> (raw)
In-Reply-To: <199804211939.PAA05064@subrogation.cygnus.com>
>
> From: hjl@lucon.org (H.J. Lu)
> Date: Tue, 21 Apr 1998 12:34:46 -0700 (PDT)
>
> > Why not encourage people to write the prefix on a separate line, which
> > works for both a.out and ELF?
> >
>
> That is a separate issue. Since PREFIX_SEPARATOR is wrong on ELF, we
> should fix it. I think we can change it
>
> #define PREFIX_SEPARATOR '\\'
>
> so that everyone will be happy.
>
> I am questioning the need for PREFIX_SEPERATOR at all. I don't see
> any particular reason to use it on ELF if it is not required and if no
> other ELF assembler supports it.
The only reason I can think of is that we may want to treat prefixes
on a separate line differently to prefixes specified "with the
instruction"
eg. We might find it desirable for
ds
lgdt 0
to emit the ds prefix while
ds/ldgt 0 (or whatever the syntax is)
or
lgdt %ds:0
shouldn't. ie. gas realises that ds is the default segment.
Martynas (martynas@nm3.ktu.lt) has been working on a 16 bit capable
gas, and he's keeping track of address size prefixes as a means to
tell the assembler that the next instruction is a 16 bit one.
For instance `addr16; mov 0,%ebx' generates 67 8b 1e 00 00
while `mov 0,%ebx' generates 8b 1d 00 00 00 00
So the `addr16' can't just be emitted; It considerably effects
following code, and not just offset sizes, but modrm bytes too.
I'm wondering if this is really a good idea. Maybe it would be better
if addr16 didn't effect the code generated, and instead we require a
`.code16' directive.
How do other unix assemblers handle 16 bit code? Or don't they?
Can someone with access to Unixware, SCO, etc. assemblers do some
experimentation please?
prev parent reply other threads:[~1998-04-21 17:45 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-04-21 11:41 H.J. Lu
1998-04-21 11:54 ` Ian Lance Taylor
1998-04-21 12:32 ` H.J. Lu
1998-04-21 12:39 ` Ian Lance Taylor
1998-04-21 12:39 ` H.J. Lu
1998-04-21 12:39 ` Ian Lance Taylor
1998-04-21 12:32 ` Martynas Kunigelis
1998-04-21 12:34 ` Ian Lance Taylor
1998-04-21 12:34 ` H.J. Lu
1998-04-21 12:39 ` Ian Lance Taylor
1998-04-21 17:45 ` Alan Modra [this message]
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=199804220045.KAA02314@mullet.Levels.UniSA.Edu.Au \
--to=alan@spri.levels.unisa.edu.au \
--cc=gas2@cygnus.com \
--cc=hjl@lucon.org \
--cc=ian@cygnus.com \
--cc=martynas@nm3.ktu.lt \
/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).