On 2008-02-16, Oleg Verych <[email protected]> wrote:
> Grant Edwards @ Fri, 15 Feb 2008 15:00:49 +0000 (UTC)
>>
>> On 2008-02-15, Oleg Verych <[email protected]> wrote:
>>
>>>> If you have to deal with data layed out like that, there's
>>>> nothing you can do besides doing byte-by-byte access of the
>>>> misaligned fields. You simply can't have both u1 and u2
>>>> aligned.
>>>
>>> This is problem of high-level design, or blame whatever you
>>> want (e.g. 8-bit past, Intel+MS hegemony, C and its
>>> "implementation-defined"), but not msp430 toolchain.
>>
>> Correct. The problem is not the fault of the msp430 toolchain.
>>
>> However, other toolchains (including other gcc targets) provide
>> a solution to the problem, while the msp430 toolchain does not.
>> What's worse is the compiler _pretends_ to implement a solution
>> by siliently emitting incorrect code.
>
> Hope, you will agree, that packed attr. and alignment are two
> different things.
They're very closely related.
>> IMO, since the packed struct feature works correctly on other
>> gcc targets it's quite reasonable for an mspgcc user to expect
>> that packed structs work on the msp430 target. A bug is when a
>> product doesn't do what a user reasonably expects it to do --
>> regardless of the intentions of the developers. If you're not
>> going to implemenent accesses to fields of packed structs, then
>> it should be an error when the user attempts to do so.
>
> And GCC does this two things differently.
I don't understand.
> Which is quite OK, when developers have limited time and money
> to spend. More, AFAIK, attr. packed yields inefficient code
> for _any_ access to a structure (on those archs), which forces
> programmer, who wants to write efficient code, to make own
> tools and to disable GCC's features.
Generating inefficient code should _always_ takes absolute
priority over generating incorrect code. If all you care about
is efficiency, then I can write you a bang-up compiler that
will compile all programs into a hyper-efficient program
consisting of a single "RET" instruction.
>>> C was meant to be a macro-language for PDP-11 or something
>>> like that.
>>
>> No it wasn't.
>
> "For the first time in 1970, the Unix operating system was
> officially named and ran on the PDP-11/20."[1]
You are correct. For some reason I read your statement
backwards. C was based on BCPL (which pre-dates the PDP-11),
and was a general purpose programming language. IIRC, it
wasn't designed specifically for the the PDP-11, that just
happens to be the spare hardware that somebody found in a lab
somewhere to play with.
> What i mean by text-processing is, that change code.c,
> depending of what programmer wants (details and features must
> be known). For example to analyze codebase for possible
> unaligned access and to substitute it with access methods
> needed, if another target or more efficient code is going to
> be implemented. [...]
Sorry, I've no idea what you're saying. That it's OK for a
compiler to generate incorrect code as long as it runs fast?
--
Grant Edwards grante Yow! It's OKAY --- I'm an
at INTELLECTUAL, too.
visi.com
