Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » MSPGCC
  • » [Mspgcc-users] text processing (Re: unaligned data (Re: msp-gcc does not support packed struct?)) [RSS Feed]

#1 Feb. 16, 2008 03:38:28

Oleg V.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] text processing (Re: unaligned data (Re: msp-gcc does not support packed struct?))


Grant Edwards @ Fri, 15 Feb 2008 15:00:49 +0000 (UTC)
>
> On 2008-02-15, Oleg Verych <!gmane?olecom.eno***@*lower.upol.cz> 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.

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

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

"C is a general-purpose, block structured, procedural, imperative
computer programming language developed in 1972 by Dennis Ritchie at
the Bell Telephone Laboratories for use with the Unix operating
system."

http://en.wikipedia.org/wiki/C_%28programming_language%29http://en.wikipedia.org/wiki/Unix> C was always a compiled language,

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. It's not statically patching code or even ugly
#ifdefs. This also can allow run time unaligned access debugging -- you
are inserting printf() to check data, or catch CPU exceptions by text
processing, but not bloating code and leaving possible bugs, if you've
forget to check some other functions manually.

And if text patterns and scripts are shared among programmers, this
can help to solve many problems. Just raw C code isn't that useful any
more. Also, if programmers will know how to write easily readable for
text-tools code, then code will be more readable for humans.

* Coding styles in BSDs and Linux kernel, thus, technically (not,
religiously) are not needed crutches;

* python is poor parody on all this;

* perl is assassin of BREs + `sed`.

Some interesting example are in .

http://en.wikipedia.org/wiki/Kernel_Normal_Formhttp://lxr.linux.no/linux/Documentation/CodingStylehttp://www.advogato.org/person/olecom/diary/3.htmlI also think, that validity and security of new code can be made a bit
higher. When textbook security holes (dereferencing user supplied
pointer, length whatever without prior checking) are put, is it OK NOW?http://www.securityfocus.com/archive/1/487982http://lwn.net/Articles/268420/Even worse, is it OK to have buggy official fixes for that???http://lwn.net/Articles/268664/This is much more ugly and stupid, than structures without a clue
about, what alignment is.
________

Offline

#2 Feb. 16, 2008 06:12:13

Grant E.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] text processing (Re: unaligned data (Re: msp-gcc does not support packed struct?))


On 2008-02-16, Oleg Verych <!gmane?olecom.eno***@*lower.upol.cz> wrote:
> Grant Edwards @ Fri, 15 Feb 2008 15:00:49 +0000 (UTC)
>>
>> On 2008-02-15, Oleg Verych <!gmane?olecom.eno***@*lower.upol.cz> 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."

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

Offline

#3 Feb. 16, 2008 06:28:04

Oleg V.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] text processing (Re: unaligned data (Re: msp-gcc does not support packed struct?))


Grant Edwards @ Sat, 16 Feb 2008 06:11:52 +0000 (UTC)

>> 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?

Yes, if this is 90% or more cases (experimentally, e.g. how often this
question was addressed here). Otherwise tools must be expanded or fixed.

I think, former is easier way, but probably not understood to evaluate,
by way i present it.

And as it seems, latter is problem of developer's views (current state of
the MSP430 toolchain) or/and money (to pay for implementing feature,
someone wants/"thinks, is correct").
________

Offline

#4 Feb. 16, 2008 14:50:38

Grant E.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] text processing (Re: unaligned data (Re: msp-gcc does not support packed struct?))


On 2008-02-16, Oleg Verych <!gmane?olecom.eno***@*lower.upol.cz> wrote:

>> 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?
>
> Yes, if this is 90% or more cases (experimentally, e.g. how often this
> question was addressed here). Otherwise tools must be expanded or fixed.

I completely disgree. It is _never_ acceptible for a compiler
designer/maintainer to decide that it's OK for the compiler to
generate incorrect code because the correct code would be less
efficient. Generating the wrong answer quickly is worse that
usless.

> I think, former is easier way, but probably not understood to
> evaluate, by way i present it.
>
> And as it seems, latter is problem of developer's views
> (current state of the MSP430 toolchain) or/and money (to pay
> for implementing feature, someone wants/"thinks, is correct").

What all the other targets do is correct.

--
Grant Edwards grante Yow! I am a traffic light,
at and Alan Ginzberg kidnapped
visi.com my laundry in 1927!

Offline

#5 March 22, 2008 20:04:22

Oleg V.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[Mspgcc-users] text processing (Re: unaligned data (Re: msp-gcc does not support packed struct?))


>> C was always a compiled language,
>
> 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. It's not statically patching code or even ugly
> #ifdefs.

I'm not surprised, that "Einstein of our time" had similar ideas
about assembler with powerful text-processing macro functionality vs C
in the Ph.D work.

Wonderful work, but unfortunately useless for current main stream toester
(like in `xbill`) hardware...

http://www.wired.com/wired/archive/4.12/ffmassalin.html and on to bottom.http://citeseer.ist.psu.edu/massalin92synthesi.html______

Offline

  • Root
  • » MSPGCC
  • » [Mspgcc-users] text processing (Re: unaligned data (Re: msp-gcc does not support packed struct?)) [RSS Feed]

Board footer

Moderator control

Enjoy the 11th of December
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support