Re: SixPacks mods for GCIC users

--- In [email protected], Ivan Warren <ivan@...> wrote:
>
> On 11/6/2010 2:37 PM, kerravon86 wrote:
> >>
> >> In this case the LM 0,1,0(3) gives erratic results.
> >
> > Erratic? It should have given a specification
> > exception, shouldn't it? 3/4 of the time.
> >
> 
> No way !
> 
> There is no imposed alignment on the LM instruction.
> 
> If an unaligned LM gives incorrect results, produces a machine check or 
> kills hercules on a host that imposes 32 bit alignments for fetches, 
> then it's a hercules issue.
> 
> On my own ARM experimentation, I encountered a few of those, but they 
> might crept back in due to the fact ARM is seldom used as a hercules host.
> 
> The reason for this to happen is because we might - at some point - cast 
> an arbitrary storage location to a unsigned 32 bit value - and then the 
> optimizer will infer that it *IS* aligned. The issue is that it's 
> sometime a bit tricky to track because the cast can be quite far from 
> where the issue occurs.
> 
> Unfortunately, for the time being, I don't have any ARM setup (although 
> I still have the hardware stowed somewhere in a box.. A WRTG54G router) 
> - but I'd have to re-install linux on it (I think I should be able to 
> use OpenWRT for that).
> 
> --Ivan
>

Ivan,

I obtained a complete scheme of the failing LM instruction
 using a little test program.

I have the following  fields:

ALIGN  DS 0F
DISPLACE DS CL0   (or 1,2,3)
FIELD1 DC C'ABCDEFGH'
FIELD2 DC C'12345678'

and I do:

TEST  LM 6,7,FIELD2

I get in R6 and R7 (varying the DISPLACE LENGTH)

DISPLACE = 0 : 1234 5678 (correct)
DISPLACE = 1 : 123H 5674
DISPLACE = 2 : 12GH 5634
DISPLACE = 3 : 1FGH 5234

This scheme gave me the wrong idea of 'erratic' behaviour;-) 

BFN

Paul