Re: Re: SixPacks mods for GCIC users

On 11/6/10 10:50 PM, Ivan Warren wrote:
>> 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.
>
> 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).

   Oh my yes, I'm pretty sure there were more multiprocessor systems 
built around MIPS processors than any other architecture, except for 
possibly SPARC.

   ARM has supported multiprocessor configurations since ARM11 MPCore, 
which was released around 2004.

   As to the atomicity of multibyte loads and stores on ARM, I'm 
honestly not sure, but we should be able to find that info.

> - 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).

   Yeah, casting or copying between pointers and integers has been 
dissuaded since the very first edition of the K&R book. ;)  There should 
be a clean way to create a generic alignment fixup routine for handling 
stuff like this, that's parameterizable at compilation time for the 
target architecture's specific access alignment requirements.

> 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).

   I'd think it should just generate an alignment trap and be fixed up 
(with a performance penalty) by the trap handler.

             -Dave

-- 
Dave McGuire
Port Charlotte, FL