[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:55:10 +0300 |
helper_fullwr will call memory_write if it does not go to [0x0000 - 0x0100)
range otherwise it will call cpu_outb because this range has a dual access
through ST and OUT instructions
On Wed, Jul 6, 2016 at 12:52 PM, Peter Maydell <address@hidden>
wrote:
> On 6 July 2016 at 10:36, Michael Rolnik <address@hidden> wrote:
> > 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
>
> This doesn't sound right -- if helper_fullwr is for memory writes
> it shouldn't call cpu_outb, which is IO space.
>
> The distinction here is between different kinds of what QEMU
> calls "address spaces".Pretty much every CPU has an address
> space for "memory", which is what you can access via the usual
> load and store instructions. Some CPUs also have an address
> space for "IO", if they have dedicated different IO instructions.
> The usual example of this is x86 -- an X86 "outb" instruction to
> port 0 is different from store-byte to memory address 0. So
> we have an address space for the "io space" which inb/outb/etc
> access, and one for memory which loads and stores access.
> Most CPUs don't have this kind of split idea of device IO
> as different from memory access (their devices are "memory
> mapped"); our models of these CPUs don't have an address
> space for IO, because there isn't one in the real hardware.
>
> It looked to me from glancing through the data sheet that these
> IO registers in your CPU are accessed via normal memory loads
> and stores, which would mean that the devices for them should
> go in the usual address space for memory, not a different
> one for IO, and you shouldn't call cpu_outb at all.
>
> 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, 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, 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 <=
- 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, 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, Richard Henderson, 2016/07/06