RE: Re: SixPacks mods for GCIC users

Hello!
The correct expression is "Something is rotten in Denmark.", and Hamlet did
say it, but I can't recall where in the play it is said. By the way Vanya
Doctor Smith is the only expert here, I do know enough about the Bard to
give someone a good argument.

---
Gregg C Levine [email protected]
"This signature is not the same one. Move along! Move along!"

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Ivan Warren
Sent: Saturday, November 06, 2010 10:50 PM
To: [email protected]
Subject: Re: [H390-VM] Re: SixPacks mods for GCIC users

On 11/7/2010 1:56 AM, Dave McGuire wrote:
> On 11/6/10 3:50 PM, paoloG wrote:
>>> And what makes you think it is ARM-specific? It
>>> might be a Herc bug if it's not abending on the
>>> other environments.  Although VM may be intercepting
>>> that. Which would make a separate VM bug.
>>>
>>> Or am I missing something?
>>
>> I had this behaviour only in Hercules ARM version
>>
>> (I tried VM/370 on Intel x86, SPARC, PowerPC and it worked fine)
>
>     If it works with the same release of Hercules on x86, SPARC, and PPC,
> but fails on ARM, then it's either a bug in Hercules or a bug in the
> host machine's C compiler or assembler...no ifs, ands, or buts.
>
>     Hercules is very portable and host-architecture-agnostic; I'm
> surprised to see this happening at all.  And ARM is one of the most
> widely-deployed processor architectures in the world today (if not THE
> most widely-deployed); compilers for ARM are generally pretty
> well-debugged at this point.  This is very strange indeed.
>
>              -Dave
>

The compiler - and the code is host architecture agnostic (for the most 
part)..

However, hercules DOES have a few bits that are a bit outside the C 
standards :

- 1) We are assuming that accessing (fetching or storing) a 32 bit 
aligned value from memory is MP safe (that is the value is atomically 
fetched/stored). We pretty much it's always true on Intel arch and on 
ESA/390 - z/Arch itself.. I'm pretty sure it also hold on PowerPC.. Not 
sure about MIPS, SPARC or ARM(Not sure ARM or MIPS has Multi processor 
anyway).

- 2) (And that's the problem here) : we're casting values to types that 
MAY require alignment on some host architectures.. We have a specific 
build flag for this (whether the host requires aligned access.. 16 bit 
alignment for 16 bit access, 32 bit alignment for 32 bit access, 
etc..).. However, there are SOME instances (as noted with LM) where 
we're missing either a conditional compile or a miscast. I need to check 
the C standard about it - but it's probably going to tell me I shouldn't 
be casting a pointer to a unsigned 32 bit integer without knowing it 
ACTUALLY is an unsigned 32 bit integer for the the host I'm running on 
(including alignment).

I'm a little surprised to hear people are getting inconsistent results . 
I would certainly have expected a machine check - due to SIGSEGV or 
SIGBUS - But bad data ? There certainly something wrong in the state of 
Denmark (as Hamlet.. or Greg Smith - Our own expert in those matters 
would say).

--Ivan