Re: [Qemu-devel] [PATCH V3 2/7] nios2: Add architecture emulation support

[Richard Henderson]

On 10/18/2016 08:23 PM, Marek Vasut wrote:
> > The documentation appears less than clear about whether or not loads
> > into r0 recognize exceptions from the load, as opposed to simply not
> > modifying r0.
>
> What about [1] page 10, quote:
>
> The Nios II architecture provides thirty-two 32-bit general-purpose
> registers, r0 through r31. Some registers have names recognized by the
> assembler. For example, the zero register (r0) always returns the
> value zero, and writing to zero has no effect.

I read that, but is that "... writing to zero has no effect [on the zero 
register]" but loads still take mmu faults, or, as other architecture manuals 
usually call out explicitly, "loads to the zero register are prefetch 
instructions and do not fault".

Other architectures are split on this issue.  For instance HPPA, Sparc, MIPS 
all fault when loading to the zero register from a protected page.  Alpha 
*initially* reported such faults, but later changed the spec to be a prefetch 
(and therefore kernels supporting ev4 are supposed to recognize such loads and 
return without reporting the SIGSEGV).

Do you have hardware that you can test this against?  If a load to zero is a 
prefetch, the nios2 gcc port is missing the prefetch pattern.  ;-)

Either way, a comment would clear this up for future maintainers.

> > > +/* Branch instructions */
> > > +static void br(DisasContext *dc, uint32_t code, uint32_t flags)
> > > +{
> > > +    I_TYPE(instr, code);
> > > +
> > > +    gen_goto_tb(dc, 0, dc->pc + 4 + (int16_t)(instr.imm16 & 0xFFFC));
> >
> > Probably clearer as pc + 4 + (instr.imm16s & -4)
>
> I disagree, the 0xfffc in my opinion clearly states it removes bottom
> two bits. Doing bitops with signed number looks real iffy.

It also removes the top 16 bits, requiring you to sign-extend again.

You might like 0xfffffffc better, but that does require that you count f's 
appropriately for the type.  That's why I like -4: it's obvious (or should be) 
that it masks to a multiple of 4, and type promotion extends bits to the left 
as needed for the type of the other AND argument.


r~