filling remaining array elements with fixed value

Hi Randy,

On 6/12/2014 3:02 PM, Randy Yates wrote:
> Grant Edwards<invalid@invalid.invalid>  writes:
>> On 2014-06-12, Randy Yates<yates@digitalsignallabs.com>  wrote:
>>
>>> I go along with the others who suggested that you write some C/C++ code
>>> to generate this code. I've done that many times and it works well.
>>
>> I find it's usually _way_ faster to write a Python program to generate
>> such things, but YMMV.
>
> Yeah, sure, python, perl, common lisp, scheme, erlang, c, c++, etc. -
> pick yer' poison.

Write it in the same language that you are compiling -- that way you
*know* you have THAT tool available wherever you happen to maintain
the codebase (instead of having to have *two* tools).

E.g., if I'm embedding a large struct into a Limbo module, I
write the "converter" in Limbo as well.  Doesn't do me much
good to write it in C if I can't be assured having a C compiler
alongside the Limbo compiler!

It also eases the requirements on the developer (he may know C
but *not* Python, Scheme, etc. -- or, not as well!).

On 12/06/14 22:07, Randy Yates wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 12/06/14 19:54, Tim Wescott wrote:
>>> On Thu, 12 Jun 2014 12:27:05 -0500, Joe Chisolm wrote:
>>>
>>>> On Thu, 12 Jun 2014 11:12:02 -0500, Tim Wescott wrote:
>>>>
>>>>> On Thu, 12 Jun 2014 09:31:33 -0500, Joe Chisolm wrote:
>>>>>
>>>>>> On Thu, 12 Jun 2014 10:30:37 +0200, blisca wrote:
>>>>>>
>>>>>>> Hi to all here
>>>>>>>
>>>>>>>
>>>>>>> Using Codewarrior,GNU i want to declare an  array in program memory
>>>>>>> like this:
>>>>>>>
>>>>>>> const unsigned char
>>>>>>> my_array[8]={0xA,0xB,0xC,0xFF,0xFF,0xFF,0xFF,0xFF};
>>>>>>>
>>>>>>> Is there any convenient way to do it if the array is 1024 elements
>>>>>>> wide?
>>>>>>>
>>>>>>> Many thanks
>>>>>>>
>>>>>>> Diego
>>>>>>
>>>>>> my_array[1024] = {[0 ... 1023] = 0xFF, [0]=0x0A, [1]=0x0B, [2]=0x0C};
>>>>>>
>>>>>>   From the gcc docs "If the same field is initialized multiple times, it
>>>>>> will have value from the last initialization."
>>>>>>
>>>>>> search for gcc array initializer
>>>>>
>>>>> I wouldn't want to trust that for code that needs to live a long life.
>>>>> If your product life cycle is only a year or two, then that looks like
>>>>> a nifty feature to exploit.
>>>>
>>>> Why would you not trust it for a long life product.  Granted the OP
>>>> would be better with some defines with better names.  The array init
>>>> feature has been in gcc for something like 10 years now.  I dont think
>>>> they are going to rip it out.  You have to be careful about initializer
>>>> values with side effects but that is not the issue here.
>>>
>>> Because even if I could trust gcc not to rip it out, I couldn't trust
>>> that, over the lifetime of the code, the need to change tools wouldn't
>>> arise.
>>>
>>> I've been in industry for over 20 years.  Using some clever non-standard
>>> compiler feature -- or even some feature that's in some clever but dusty
>>> corner of the standard -- makes you look like a hero for about a year,
>>> then makes you look like a fool.
>>>
>>> Over time, one becomes allergic.
>>>
>>
>> I also have been in the industry for 20 years.  And over the lifetime
>> of a project, I almost never change tools.  Just a few weeks ago I had
>> to make changes to a program that I wrote 18 years ago - I compiled it
>> with the same compiler I used 18 years ago (despite having much newer
>> and much better tools for the same target).
>>
>> So if I write code that takes advantage of a particular feature of a
>> compiler, I know that it will still work in the future.  And in
>> practice, I seldom write code that does not involve at least some
>> compiler-specific feature somewhere in the project (such as pragmas or
>> function attributes for interrupt functions, etc.).
>>
>> Using compiler features like this one is perfectly safe.  Within the
>> project, you will be (or should be!) using the same tools all the time
>> -
>> thus it still works in the same project.  And if you re-use the code
>> in a different project, then it either works fine (because you are
>> using gcc again, or a compiler that supports the same extensions), or
>> you get an error from your compiler.  It is /highly/ unlikely that
>> some other compiler will silently accept this syntax but interpret it
>> in a different way.
>>
>> Of course if you know (or strongly suspect) that the code you are
>> writing has to work across a range of compilers, then you must avoid
>> extensions.  But if you are writing project-specific code, or just use
>> the one compiler, then take advantage of any extensions that lead to
>> cleaner and neater code - just as you use other features of your
>> tools.
>
> What you say is clearly correct, but many times tools are not "stored"
> with the project. I don't know about others, but for myself, it's just
> often too much a pain to make sure I get all the components of gcc/g++
> (or whatever) into my version control. Although on my current project I
> have done just that.
>
> But I agree this is the ideal, anal way to go about things.
>

I typically don't include the tools in the version control system - gcc 
is not too bad, but trying to get something like CodeWarrior into 
subversion would be a serious pain.  But we archive downloaded tools, 
install them in carefully named directories, and refer to those 
directories in makefiles.  And I avoid updating tools - if I need a new 
version because of a serious bug fix, or simply to get the latest and 
greatest at the start of a new project, I install the new version in a 
new directory.  We also make a point of avoiding tools that get locked 
to particular computers or have other such restrictions (floating 
licenses are a much better choice), and "archive" old development PC's.

On 13/06/14 00:07, Tim Wescott wrote:
> On Thu, 12 Jun 2014 21:27:33 +0200, David Brown wrote:
>
> << snip >>
>
>> Of course if you know (or strongly suspect) that the code you are
>> writing has to work across a range of compilers, then you must avoid
>> extensions.  But if you are writing project-specific code, or just use
>> the one compiler, then take advantage of any extensions that lead to
>> cleaner and neater code - just as you use other features of your tools.
>
> Toward the end of my corporate career I often ended up writing code that
> would get reused.
>
> Using "special" features of the compiler was also discouraged because it
> required code reviewers to know what the compiler would actually do -- we
> tended to stress clarity over convenience, as long as the running code
> was not seriously impacted.
>

If you have to compile the same code on multiple compilers, then you are 
restricted to a common subset (or perhaps messy macros and conditional 
compilation to deal with differences).

The same applies to multiple developers or reviewers, I suppose - you 
are limited to using a common subset that they are all happy with.  That 
applies to standard features as well as compiler enhancements - just 
because code follows the "legal" C standards, does not mean it will be 
comprehensible to others!

I firmly agree with stressing clarity over convenience.  Some gcc 
enhancements, such as the array initialisation, case ranges, typeof, 
etc., can definitely improve clarity.  Others such as function 
attributes can improve code quality while still being perfectly clear in 
function.  But some, such as nested functions or "conditionals with 
omitted operands" are going to be far too confusing even in the few 
cases where they might be of interest.

On 13.06.2014 00:20, Don Y wrote:

> Write it in the same language that you are compiling -- that way you
> *know* you have THAT tool available wherever you happen to maintain
> the codebase (instead of having to have *two* tools).

Except when you don't, which would tend to apply to people in this 
newsgroup more than any other group.

Just because you're already writing embedded software in C doesn't mean 
you'll also have a "native" C compiler for your desktop OS anywhere near 
you.

On Fri, 13 Jun 2014 00:37:52 +0200, David Brown wrote:

<< snip >>

> The same applies to multiple developers or reviewers, I suppose - you
> are limited to using a common subset that they are all happy with.  That
> applies to standard features as well as compiler enhancements - just
> because code follows the "legal" C standards, does not mean it will be
> comprehensible to others!
> 
> I firmly agree with stressing clarity over convenience.  Some gcc
> enhancements, such as the array initialisation, case ranges, typeof,
> etc., can definitely improve clarity.  Others such as function
> attributes can improve code quality while still being perfectly clear in
> function.  But some, such as nested functions or "conditionals with
> omitted operands" are going to be far too confusing even in the few
> cases where they might be of interest.

I still have my copy of Harbison & Steele from when I started my career, 
with the page marked so that I could easily look up the order of operator 
precedence and save on using all those confusing parenthesis in my long 
mathematical or logical expressions.

I was cured of _that_ habit when I started working in an environment 
where my code got reviewed.  Quickly and emphatically, I might add.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On 13/06/14 01:19, Tim Wescott wrote:
> On Fri, 13 Jun 2014 00:37:52 +0200, David Brown wrote:
>
> << snip >>
>
>> The same applies to multiple developers or reviewers, I suppose - you
>> are limited to using a common subset that they are all happy with.  That
>> applies to standard features as well as compiler enhancements - just
>> because code follows the "legal" C standards, does not mean it will be
>> comprehensible to others!
>>
>> I firmly agree with stressing clarity over convenience.  Some gcc
>> enhancements, such as the array initialisation, case ranges, typeof,
>> etc., can definitely improve clarity.  Others such as function
>> attributes can improve code quality while still being perfectly clear in
>> function.  But some, such as nested functions or "conditionals with
>> omitted operands" are going to be far too confusing even in the few
>> cases where they might be of interest.
>
> I still have my copy of Harbison & Steele from when I started my career,
> with the page marked so that I could easily look up the order of operator
> precedence and save on using all those confusing parenthesis in my long
> mathematical or logical expressions.
>
> I was cured of _that_ habit when I started working in an environment
> where my code got reviewed.  Quickly and emphatically, I might add.
>

I have intentionally never learned the full precedence rules for C 
operators, to avoid that temptation!

I found it quite interesting to look through the old code, both in what 
has changed and what has stayed the same.  Some of it was obvious - this 
was pre-C99 code, so no // comments or mixed declarations and 
statements, and my own fixed-size integer types.  There was also very 
little use of file-level "static", which I now use everywhere.

On 13/06/14 01:15, Hans-Bernhard Br�ker wrote:
> On 13.06.2014 00:20, Don Y wrote:
>
>> Write it in the same language that you are compiling -- that way you
>> *know* you have THAT tool available wherever you happen to maintain
>> the codebase (instead of having to have *two* tools).
>
> Except when you don't, which would tend to apply to people in this
> newsgroup more than any other group.
>
> Just because you're already writing embedded software in C doesn't mean
> you'll also have a "native" C compiler for your desktop OS anywhere near
> you.
>

If you are using Linux then you will always have a native C compiler 
handy.  Of course, you will also have Python, which is a much nicer 
language for this sort of scripting (it's quick to learn enough Python 
to write such scripts).

In article <lnd9ll$nja$1@dont-email.me>,
David Brown  <david.brown@hesbynett.no> wrote:
>On 12/06/14 22:07, Randy Yates wrote:
>> What you say is clearly correct, but many times tools are not "stored"
>> with the project. I don't know about others, but for myself, it's just
>> often too much a pain to make sure I get all the components of gcc/g++
>> (or whatever) into my version control. Although on my current project I
>> have done just that.
>>
>> But I agree this is the ideal, anal way to go about things.
>>
>
>I typically don't include the tools in the version control system - gcc 
>is not too bad, but trying to get something like CodeWarrior into 
>subversion would be a serious pain.  But we archive downloaded tools, 
>install them in carefully named directories, and refer to those 
>directories in makefiles.  And I avoid updating tools - if I need a new 
>version because of a serious bug fix, or simply to get the latest and 
>greatest at the start of a new project, I install the new version in a 
>new directory.  We also make a point of avoiding tools that get locked 
>to particular computers or have other such restrictions (floating 
>licenses are a much better choice), and "archive" old development PC's.

...thread drift...

We currently have a setup to do nightly builds of all our code.  We've 
seriously considered, but haven't pulled the trigger yet, on also setting
up a build on a virtual machine.  This build on the virtual machine 
wouldn't happen as often, but the virtual machine snapshot would theoretically
capture "everything".  The virtual machine snapshot could then be
checked into revision control.   

Sounds like overkill, but it some industries, being able to faithfuly rebuild 
something 5, 10, 15+ years down the line could be useful...

Regards,

Mark

Hi David,

On 6/12/2014 5:04 PM, David Brown wrote:
> On 13/06/14 01:15, Hans-Bernhard Br�ker wrote:
>> On 13.06.2014 00:20, Don Y wrote:
>>
>>> Write it in the same language that you are compiling -- that way you
>>> *know* you have THAT tool available wherever you happen to maintain
>>> the codebase (instead of having to have *two* tools).
>>
>> Except when you don't, which would tend to apply to people in this
>> newsgroup more than any other group.
>>
>> Just because you're already writing embedded software in C doesn't mean
>> you'll also have a "native" C compiler for your desktop OS anywhere near
>> you.
>
> If you are using Linux then you will always have a native C compiler
> handy. Of course, you will also have Python, which is a much nicer
> language for this sort of scripting (it's quick to learn enough Python
> to write such scripts).

Regardless of host, the folks *maintaining* the code will be KNOWN
to be knowledgeable in *that* (language).  Not necessarily the case
for C++, sh, perl, python, etc.

There are often little differences in languages to which users are
completely oblivious -- that can make significant differences in
their comprehension of an algorithm expressed in a language that
they may only *casually* know.

[E.g., ARBNO() is a lazy matcher in SNOBOL.  Folks coming from a
C background (with it's typical greedy matches in regex library)
will completely misunderstand the mechanics of ARBNO and incorrectly
emulate it's function.]

Early in my career, I was "too clever, by half" and relied on
my wider experience/tool base in crafting solutions to problems.
Mixing various tools, languages, environments to give me an
"optimal" (in terms of development effort) solution.  E.g., I
was running SysV UNIX w/X at home in the early 80's -- while
others were fighting with MS, funky memory models, "overlays",
and *waiting* for (illusion of) a "multitasking, GUI environment,
etc.

Almost all of those solutions eventually trapped me into ongoing
support roles ("But we don't have UNIX, here!"  "But Joey doesn't
know perl!"  "But I don't want to have to purchase...").  And, so,
after-the-fact, I found myself back-porting designs to the very
same "crippled" environments from which I had originally "cleverly"
freed myself (lest I be stuck in an ongoing support role... "life
is way too short to spend in support!")

I'm in a similar predicament, currently:  do I rely on expensive
tools that I own and "force" others wanting to maintain my
designs to also purchase them?  Or, do I discard my tools and
my experience with them *just* to make it LESS EXPENSIVE for
others?

Time to make some ice cream...

On 2014-06-12, Don Y <this@is.not.me.com> wrote:
> Hi Randy,
>
> On 6/12/2014 3:02 PM, Randy Yates wrote:
>> Grant Edwards<invalid@invalid.invalid>  writes:
>>> On 2014-06-12, Randy Yates<yates@digitalsignallabs.com>  wrote:
>>>
>>>> I go along with the others who suggested that you write some C/C++ code
>>>> to generate this code. I've done that many times and it works well.
>>>
>>> I find it's usually _way_ faster to write a Python program to generate
>>> such things, but YMMV.
>>
>> Yeah, sure, python, perl, common lisp, scheme, erlang, c, c++, etc. -
>> pick yer' poison.
>
> Write it in the same language that you are compiling -- that way you
> *know* you have THAT tool available wherever you happen to maintain
> the codebase (instead of having to have *two* tools).

I don't understand. If I'm writing in C for the '430, how does that
guarantee I have C for the development host?

-- 
Grant