On 15/05/2015 14:43, Richard Henderson wrote:
> On 05/15/2015 05:09 AM, Leon Alrae wrote:
>> On 14/05/2015 20:12, Richard Henderson wrote:
>>> /* We know both pages are present and writable. */
>>> if (eaddr == baddr + 15) {
>>> /* Consecutive pages in RAM. */
>>> memcpy(baddr, re
On 05/15/2015 05:09 AM, Leon Alrae wrote:
> On 14/05/2015 20:12, Richard Henderson wrote:
>> /* We know both pages are present and writable. */
>> if (eaddr == baddr + 15) {
>> /* Consecutive pages in RAM. */
>> memcpy(baddr, register, 16);
>> } else {
>> /* Someone's doin
On 14/05/2015 20:12, Richard Henderson wrote:
> /* We know both pages are present and writable. */
> if (eaddr == baddr + 15) {
> /* Consecutive pages in RAM. */
> memcpy(baddr, register, 16);
> } else {
> /* Someone's doing an MSA store to device memory. */
> for (
On 05/14/2015 08:27 AM, Richard Henderson wrote:
> Perhaps
>
> void probe_read(CPUArchState *env, target_ulong addr, int mmu_idx,
> uintptr_t retaddr);
>
> void probe_write(CPUArchState *env, target_ulong addr, int mmu_idx,
> uintptr_t r
On 05/14/2015 02:46 AM, Yongbok Kim wrote:
> In addition to that, if we issue all the loads let say only the first page is
> accessible, in the architectural point of view it would be fine as nothing
> will
> be stored in the vector register but accessing the first page is "visible"
> from
> the
On 05/14/2015 02:50 AM, Leon Alrae wrote:
> Just to confirm -– before using helper_ret_*_mmu directly we should also
> check if we can take fast-path (not sure if “fast-path” is correct term
> in this case as we've already generated a call to helper function...):
>
> if (unlikely(env->tlb_tabl
On Thu, 14 May 2015, Leon Alrae wrote:
> > I don't think we have. The specification is a bit unclear I must admit
> > and it also defines the details of vector load and store operations as
> > implementation dependent, so there's no further clarification.
>
> This is specified in "MIPS Archit
On 13/05/2015 20:28, Richard Henderson wrote:
> As an aside, consider moving away from
>
> #define HELPER_LD(name, insn, type) \
> static inline type do_##name(CPUMIPSState *env, target_ulong addr, \
> int mem_idx)
On 14/05/2015 10:00, Yongbok Kim wrote:
> On 13/05/2015 20:28, Richard Henderson wrote:
>> On 05/13/2015 08:37 AM, Yongbok Kim wrote:
>>> +static inline void ensure_atomic_msa_block_access(CPUMIPSState *env,
>>> + target_ulong addr,
>>> +
On 13/05/2015 20:28, Richard Henderson wrote:
> On 05/13/2015 08:37 AM, Yongbok Kim wrote:
>> +static inline void ensure_atomic_msa_block_access(CPUMIPSState *env,
>> + target_ulong addr,
>> + int rw,
On 13/05/2015 23:54, Maciej W. Rozycki wrote:
> On Wed, 13 May 2015, Richard Henderson wrote:
>
I believe the problem is that MSA vector register's size is 16-bytes
(this DATA_SIZE isn't supported in softmmu_template) and MSA load/store
is supposed to be atomic.
>>>
>>> Not really
On Wed, 13 May 2015, Richard Henderson wrote:
> >> I believe the problem is that MSA vector register's size is 16-bytes
> >> (this DATA_SIZE isn't supported in softmmu_template) and MSA load/store
> >> is supposed to be atomic.
> >
> > Not really AFAICT. Here's what the specification says[1]:
>
On 05/13/2015 02:21 PM, Maciej W. Rozycki wrote:
> On Wed, 13 May 2015, Leon Alrae wrote:
>
>>> Certainly we do. It's all in softmmu_template.h.
>>
>> I believe the problem is that MSA vector register's size is 16-bytes
>> (this DATA_SIZE isn't supported in softmmu_template) and MSA load/store
>>
On 05/13/2015 01:59 PM, Leon Alrae wrote:
> On 13/05/15 20:58, Richard Henderson wrote:
>> On 05/13/2015 12:56 PM, Maciej W. Rozycki wrote:
>>> We must have a way to deal with memory access operations issued by a
>>> single machine instruction crossing a page boundary already as this is
>>> what
On Wed, 13 May 2015, Leon Alrae wrote:
> > Certainly we do. It's all in softmmu_template.h.
>
> I believe the problem is that MSA vector register's size is 16-bytes
> (this DATA_SIZE isn't supported in softmmu_template) and MSA load/store
> is supposed to be atomic.
Not really AFAICT. Here's
On 13/05/15 20:58, Richard Henderson wrote:
> On 05/13/2015 12:56 PM, Maciej W. Rozycki wrote:
>> We must have a way to deal with memory access operations issued by a
>> single machine instruction crossing a page boundary already as this is
>> what MIPS16 SAVE and RESTORE instructions as well as
On 05/13/2015 12:56 PM, Maciej W. Rozycki wrote:
> We must have a way to deal with memory access operations issued by a
> single machine instruction crossing a page boundary already as this is
> what MIPS16 SAVE and RESTORE instructions as well as microMIPS SWP, SDP,
> SWM, SDM, LWP, LDP, LWM a
On Wed, 13 May 2015, Richard Henderson wrote:
> > +static inline void ensure_atomic_msa_block_access(CPUMIPSState *env,
> > + target_ulong addr,
> > + int rw,
> > +
On 05/13/2015 08:37 AM, Yongbok Kim wrote:
> +static inline void ensure_atomic_msa_block_access(CPUMIPSState *env,
> + target_ulong addr,
> + int rw,
> +
MIPS SIMD Architecture vector loads and stores require misalignment support.
MSA Memory access should work as an atomic operation. Therefore, it has to
check validity of all addresses for an access if it is spanning into two pages.
For a case of R5 with MSA, there is no clear solution to distingui
20 matches
Mail list logo
