qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Thiemo Seufer <ths@networkno.de>
To: Clemens Kolbitsch <clemens.kol@gmx.at>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] softmmu_header: ldb_kernel vs. ldsb_kernel
Date: Tue, 2 Oct 2007 17:50:55 +0100	[thread overview]
Message-ID: <20071002165055.GI16772@networkno.de> (raw)
In-Reply-To: <200710021815.58472.clemens.kol@gmx.at>

Clemens Kolbitsch wrote:
> hi everyone!
> i have a (maybe rather tricky) question:
> 
> why do you define 2 different inline load-functions in softmmu_header:
> 
> static inline int glue(glue(lds, SUFFIX), MEMSUFFIX)(target_ulong ptr)
> 
> vs.
> 
> static inline RES_TYPE glue(glue(ld, USUFFIX), MEMSUFFIX)(target_ulong ptr)
> 
> ??
> 
> Obviously this is for signed/unsigned access... but why do you need it? In 
> case there is a TLB miss, both functions call the same function (e.g. 
> __ldl_mmu) --> the return value cannot differ that much.
> 
> The only difference I see (that really matters) is how the bytes are copied to 
> the result-pointer (i.e. using movzbl vs. movsbl)... but that's it.

It is a cast. The generic C version for the other architectures makes
this more obvious.

> If there is some deeper reason behind that - could you please point that out 
> to me? And if there is such a thing, why is it not necessary for storing 
> (e.g. stb_kernel)??

A load (sign-)extends a value to register size, a store doesn't.

That's why you have e.g. in the MIPS instruction set LB, LBU and SB
but no SBU, it would do the same as SB.


Thiemo

  reply	other threads:[~2007-10-02 16:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070929150426.3890gmx1@mx069.gmx.net>
2007-10-02 16:15 ` [Qemu-devel] softmmu_header: ldb_kernel vs. ldsb_kernel Clemens Kolbitsch
2007-10-02 16:50   ` Thiemo Seufer [this message]
2007-10-02 17:06     ` Clemens Kolbitsch

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=20071002165055.GI16772@networkno.de \
    --to=ths@networkno.de \
    --cc=clemens.kol@gmx.at \
    --cc=qemu-devel@nongnu.org \
    /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).