[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 243404] Port to zSeries
From:       Florian Krohm <britzel () acm ! org>
Date:       2011-02-09 20:00:38
Message-ID: 20110209200038.9ECFA7CBC1 () immanuel ! kde ! org
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=243404





--- Comment #44 from Florian Krohm <britzel acm org>  2011-02-09 21:00:27 ---
(In reply to comment #43)
> 
> > (We discussed this already, so this is
> > <kind of irrelevant>
> >   More seriously, you need to redo the way the FPC is handled.
> >   ... need to consider more .. (do FP primops take rounding
> >   mode that is actually considered?  they should; do like PPC)
> >   run_innerloop_exit: you really need to check that the FPC
> >   on exit from generated code is as expected.
> >   so when fixed up, need to check it's the right value at
> >   exit of the dispatcher (if ppc does that)
> > </kind of irrelevant>
> see above, I want to start with the x86 way, but this was mostly
> done by Florian, so he has more insight.
> 

I would much prefer to implement to PPC scheme, even if it is a bit more work. 
That way we don't have to revisit it, or have to discuss whether to revisit.

> 
> > check -- are there vex own versions for:
> > +#define likely(x)       __builtin_expect(!!(x), 1)
> > +#define unlikely(x)     __builtin_expect(!!(x), 0)
> > 

Not that I could find them, but it would definitely be nice if VEX proper
provided them.

> > host_s390_insn.c
> > +#include <stdarg.h>
> > urr, is this necessary?
> 
> For va_arg. We could use __buildin_va_arg to get rid of this include.
> This is used for the instruction printing below.
> 

We could use the __builtin stuff but probably would have to check for GCC
versions that support it reliably... Perhaps using stdarg.h is simpler, as it
does not introduce an unwanted dependency on libc. Unles of course you consider
the inclusion of the file itself unwanted.

> > host_s390_disasm.[ch]
> > What's this for?  The host-side doesn't need any disassembly
> > facilities on any other platforms.
> 
> Its mostly pretty printing for the trace/profile flags.
> Maybe s390_disasm is a misnomer, what about print_instruction?
> 

Not really a misnomer (see also wikipedia :) 
In addition to disassembling during IR generation we also can disassemble the
emitted code. That is not done on other platforms but I found it quite
convenient for debugging purposes. I could have called the file
guest_s390_disasm.[ch] as well. It's neither specific to guest nor host.


> > 
> > +s390_irgen_FLOGR: "Note, that the Iop_Shl64 and
> > +      Iop_Shr64 semantics will preserve the value-to-be-shifted if the
> > +      shift-amount equals or is larger than the width of
> > value-to-be-shifted"
> > Wrong reason: The IR definition says that the behavior of these primops is
> > undefined in out of range shift cases -- regardless of what your
> > back end might do with them.
> 

Thanks for the clarification. I did not spot it in libvex_ir.h so I deduced the
semantics from ir_defs/ir_opt.c

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]