On Thu, Apr 12, 2012 at 6:29 AM, Stefan Kristiansson
<[email protected]> wrote:
> On Thu, Apr 12, 2012 at 05:40:21AM +0100, Julius Baxter wrote:
>> The following should implement and test the correct behaviour of the
>> delay slot execption bit in the supervisor register in the OR1200.
>>
>>
>> Index: rtl/verilog/or1200/or1200_except.v
>> ===================================================================
>> --- rtl/verilog/or1200/or1200_except.v        (revision 787)
>> +++ rtl/verilog/or1200/or1200_except.v        (working copy)
>> @@ -78,7 +78,8 @@
>>     except_stop, except_trig, ex_void, abort_mvspr, branch_op, spr_dat_ppc,
>>     spr_dat_npc, datain, du_dsr, epcr_we, eear_we, esr_we, pc_we, epcr, eear,
>>     du_dmr1, du_hwbkpt, du_hwbkpt_ls_r, esr, sr_we, to_sr, sr, lsu_addr,
>> -   abort_ex, icpu_ack_i, icpu_err_i, dcpu_ack_i, dcpu_err_i, sig_fp, 
>> fpcsr_fpee
>> +   abort_ex, icpu_ack_i, icpu_err_i, dcpu_ack_i, dcpu_err_i, sig_fp,
>> fpcsr_fpee,
>
> You probably want to turn off your e-mail clients line-wrapping function
> when pasting patches.

I just paste it into Gmail in the browser. Not sure if there's a
linewrap-off-feature but I'll be sure to check it out. I thought this
one was clean of those pesky things but then noticed one after I'd
sent it. I sent my git patches now with git send-email which is much
nicer than dealing with copy-paste from SVN. Maybe a CLI mail client
is a better way to go for my SVN-derived patches.

One thing on the patch, though - do we need to be tracking DSX on
instruction-fetch related exceptions? The _only_ case I can think of
is if a ITLB or IPF occurs on the delay slot when that instruction
goes over a page boundary. Is it useful to know in this case? It
should work but I haven't tested it in the software test.

Also, maybe we don't need to track DSX when doing system calls.
They're not allowed to be in delay slots anyway, so maybe we should be
clearing DSX on l.sys instructions?

Cheers

Julius
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc

Reply via email to