[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores
From: |
Michael Rolnik |
Subject: |
Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores |
Date: |
Wed, 6 Jul 2016 12:36:58 +0300 |
Peter,
I think I will do the following
1. helper fullwr will modify CPU owned registers by itself and call
cpu_outb for non owned registers
2. I will add helper fullrd that will behave like fullwr.
3. any board/model will have to install a device in the io space for
registers not owned by the CPU.
it will make sample_io.c device obsolete and make (future) devices more
independent.
what do you think?
Could you please point me to an example how to create a device in the io
space?
Michael
On Wed, Jul 6, 2016 at 12:19 PM, Peter Maydell <address@hidden>
wrote:
> On 6 July 2016 at 00:55, Richard Henderson <address@hidden> wrote:
> > On 07/05/2016 02:41 PM, Michael Rolnik wrote:
> >>
> >> right it accesses CPU registers but from helper context.
> >> the flow is as follows
> >>
> >> 1. there is a write to [0x0000: 0x0100) region
> >> 2. tlb_fill is called, it does the following
> >> a. sets env->fullwr
> >> b. calls cpu_loop_exit_restore.
> >> c. the whole block is retranslated and instead of st it generates
> >> helper_fullwr for each store within this TB.
> >> 3. helper_fullwr calls cpu_physical_memory_write
> >> 4. sample_io_write is called and register is changed since the whole
> thing
> >> is
> >> done from within a helper
> >
> >
> > It is my opinion that helper_fullwr should simply modify the respective
> > registers. There's no point adding two more layers of calls.
>
> I was also wondering if it would be simpler to also direct
> reads to a helper_fullrd, rather than having the write
> handling in the helper and the read handling in a device
> that's rather distant from it in a source-code-location sense.
> (Well, it would be simpler, also a bit slower, but how much
> do we care about the latter here?)
>
> thanks
> -- PMM
>
--
Best Regards,
Michael Rolnik
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, (continued)
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Peter Maydell, 2016/07/05
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Michael Rolnik, 2016/07/05
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Peter Maydell, 2016/07/05
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Richard Henderson, 2016/07/05
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Michael Rolnik, 2016/07/06
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Peter Maydell, 2016/07/06
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores,
Michael Rolnik <=
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Peter Maydell, 2016/07/06
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Michael Rolnik, 2016/07/06
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Peter Maydell, 2016/07/06
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Michael Rolnik, 2016/07/06
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Peter Maydell, 2016/07/06
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Michael Rolnik, 2016/07/06
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Peter Maydell, 2016/07/06
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Michael Rolnik, 2016/07/06
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Peter Maydell, 2016/07/06
- Re: [Qemu-devel] [PATCH v9 00/10] 8bit AVR cores, Michael Rolnik, 2016/07/06