* [Qemu-devel] softmmu_header: ldb_kernel vs. ldsb_kernel [not found] <20070929150426.3890gmx1@mx069.gmx.net> @ 2007-10-02 16:15 ` Clemens Kolbitsch 2007-10-02 16:50 ` Thiemo Seufer 0 siblings, 1 reply; 3+ messages in thread From: Clemens Kolbitsch @ 2007-10-02 16:15 UTC (permalink / raw) To: qemu-devel 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. 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)?? Thanks!! Clemens ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] softmmu_header: ldb_kernel vs. ldsb_kernel 2007-10-02 16:15 ` [Qemu-devel] softmmu_header: ldb_kernel vs. ldsb_kernel Clemens Kolbitsch @ 2007-10-02 16:50 ` Thiemo Seufer 2007-10-02 17:06 ` Clemens Kolbitsch 0 siblings, 1 reply; 3+ messages in thread From: Thiemo Seufer @ 2007-10-02 16:50 UTC (permalink / raw) To: Clemens Kolbitsch; +Cc: qemu-devel 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] softmmu_header: ldb_kernel vs. ldsb_kernel 2007-10-02 16:50 ` Thiemo Seufer @ 2007-10-02 17:06 ` Clemens Kolbitsch 0 siblings, 0 replies; 3+ messages in thread From: Clemens Kolbitsch @ 2007-10-02 17:06 UTC (permalink / raw) To: Thiemo Seufer; +Cc: qemu-devel > > 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. all right .. thanks for the fast answer :-) ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2007-10-02 17:06 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[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
2007-10-02 17:06 ` Clemens Kolbitsch
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).