Fundamental C question about "if" statements

Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:

(snip)

> For sure it's possible write buggy Ada code.
 
> But also, some errors that can be made in C are detected as compile-time 
> errors in Ada. A good static checker for C, or a good C compiler, could 
> also detect many of those errors.
 
> Perhaps these errors are of a kind that good and experienced C 
> programmers have learned to avoid, so the benefit will vary.

I suspect that is true for all languages. 

After not so long, you learn them, and avoid them, without even
thinking about it.
 
> For best results, the programmer must adopt an Ada mindset, which means 
> lots of application- and subject-specific types. A program that uses 
> Standard.Integer for all integer variables will not benefit from strong 
> typing.

I haven't done Ada programming, but I have worked with VHDL, which
as I understand it, derives some features from Ada.  After previously
using verilog, I find some VHDL features that seem to be extra work
for no advantage. 
 
> The Zeigler/Rational paper, which was referenced in other posts, shows 
> lower bug densities for Ada code than C code, in that environment, in 
> that application.

(snip)

-- glen

On 23/09/15 22:33, Niklas Holsti wrote:
> On 15-09-23 00:38 , Tim Wescott wrote:
> 
>> Latterly, on USENET, I have run into, and even drawn, quite a few
>> comments along the lines of "well, if you'd programmed that in Ada you
>> wouldn't have that bug" -- which might be true: maybe you wouldn't have
>> any bugs, or maybe you'd have other bugs, instead.
> 
> For sure it's possible write buggy Ada code.
> 
> But also, some errors that can be made in C are detected as compile-time
> errors in Ada. A good static checker for C, or a good C compiler, could
> also detect many of those errors.
> 
> Perhaps these errors are of a kind that good and experienced C
> programmers have learned to avoid, so the benefit will vary.

A good C programmer never makes those kinds of mistakes.  But he also
uses extensive static error checking in order to catch those mistakes
when he makes them.

So many C programmers compile without even the most basic warning flags
enabled - and often in ANSI C mode which allows much looser (and almost
inevitably, much buggier) code than C99.  They use whatever defaults
their point-and-drool IDE has given them, without understanding the
process, reading the documentation, thinking, or making an attempt to be
aware of what they are actually doing.

C as a language, and C compilers, are tools - you have to learn to use
them well in order to get the best of them.  Otherwise you are flailing
around, hammering in your screws and hitting your nails with a
screwdriver.  I would argue that another reason why Ada programming
leads to less bugs than the average C programmer is that when your
company has spent multiple tens of kilodollars on the tools, you spend
some time reading the documentation and figuring out how to use it properly.

> 
> For best results, the programmer must adopt an Ada mindset, which means
> lots of application- and subject-specific types. A program that uses
> Standard.Integer for all integer variables will not benefit from strong
> typing.

Absolutely.  And one can think in a similar way with C, but it is harder
to do - and easier to cheat.  (C++ gives much more opportunities for
stronger typing than C - some better than Ada, some not as good.)

The trouble with C is that although you can use typedefs to make new
types, it is hard to do so in a way that is both convenient and enforced
by the tools.

For example, if you have a program that needs to work with distances
that are sometimes in metres, sometimes in kilometres, you might do
something like this:

typedef unsigned int kilometres;
typedef unsigned int metres;

kilometres distanceA;
metres distanceB;

That can make code clearer, and gives you the flexibility to change the
underlying type later on.  But it does not stop you writing

void test1(void) {
	distanceA = distanceB;
}


With C, you can enforce the distinction between types by putting them
inside a struct.  (The Linux kernel does this for many types, though it
uses macro accessors rather than static inline functions.)


typedef struct {
    unsigned int x;
} kilometres;
typedef struct {
    unsigned int x;
} metres;

static inline metres kilometres_to_metres(kilometres km) {
    return (metres) { km.x * 1000 };
}

static inline kilometres metres_to_kilometres(metres m) {
    return (kilometres) { m.x / 1000 };
}

kilometres distanceA;
metres distanceB;

void test2(void) {
    distanceA = metres_to_kilometres(distanceB);
}

Now "distanceA = distanceB" is a compile-time error.  But the cost is
that your code is full of accessor functions.


Another possibility is to use Hungarian notation.  By that I mean /real/
Hungarian notation, or "Application Hungarian notation", as developed by
the Hungarian Simonyl himself - not that useless, ugly and irritating
"Systems Hungarian notation" (the nonsense of calling an unsigned
character variable ucVar, etc.) that Microsoft started using after they
employed Simonyl then totally misunderstood what he had been saying.

With Hungarian notation, you have:

typedef unsigned int distance;

distance km_distanceA;
distance m_distanceB;

void test3(void) {
	km_distanceA = m_distanceB;
}

The compiler can't help you spot the mistake, but humans can easily spot
it - the prefixes make it clear you are mixing kilometres and metres.

(Of course, this can be combined with the struct technique above if it
makes code clearer.)



In C++11, it is possible to wonderful things here.  (If you use C++,
make sure it is C++11, or C++14, because there are several key new
features that make it a vastly superior language.)



class Metre;
class Kilometre {
public:
    using rawT = unsigned int;
private:
    rawT x;
    explicit constexpr Kilometre(rawT y) : x(y) {};
public:
    constexpr rawT get() { return x; }
    explicit constexpr Kilometre() : x(0) {};
    constexpr operator Metre();
friend constexpr Kilometre operator "" _km(unsigned long long int y);
friend class Metre;
};

inline constexpr Kilometre operator "" _km(unsigned long long int  y) {
    return Kilometre(y);
}


class Metre {
public:
    using rawT = unsigned int;
private:
    rawT x;
    explicit constexpr Metre(rawT y) : x(y) {};
public:
    constexpr rawT get() { return x; }
    explicit constexpr Metre() : x(0) {};
    explicit constexpr operator Kilometre();
friend constexpr Metre operator "" _m(unsigned long long int y);
friend class Kilometre;
};

inline constexpr Metre operator "" _m(unsigned long long int  y) {
    return Metre(y);
}

inline constexpr Kilometre::operator Metre() {
    return Metre(x * 1000);
}

inline constexpr Metre::operator Kilometre() {
    return Kilometre(x / 1000);
}


Kilometre distanceA;
Metre distanceB;

void test3(void) {
    distanceA = 10_km;
    distanceA = (Kilometre) 10000_m;
    distanceB = 10_m;
    distanceB = 10_km;
    distanceA = static_cast<Kilometre>(distanceB);
    distanceA = (Kilometre) distanceB;
    distanceB = distanceA;
}

Here I have defined the conversion from Metre to Kilometre as "explicit"
(new to C++11), because it is unsafe and leads to loss of data, but the
conversion the other way is safe and can be done implicitly in the
program.  Thus "distanceA = distanceB" requires a cast, while "distanceB
= distanceA" is safe and does the conversion.


Ada will let you put together distance types with basically similar
rules, and may involve less typing to get them, but I don't think Ada
can get any safer than the C++ here.  (Ada experts are encouraged to
confirm or deny this.)

> 
> The Zeigler/Rational paper, which was referenced in other posts, shows
> lower bug densities for Ada code than C code, in that environment, in
> that application.

Remember that this was 20 years ago - C99 is a better and (somewhat)
safer language than ANSI C was, and C tools are a good deal better (20
years ago, using struct wrappers in C for type safety meant lots of
macros and probably very inefficient generated code.  These days you use
static inline functions that are nicer than macros, and the compiler
will generate efficient code).  And as shown above, the modern
alternative to Ada for safe programming is arguably C++ rather than C.

> 
>> I suspect that the most vocal proponents of Ada as being not just
>> technically better, but the be-all, end-all are not representative of the
>> entire Ada community -- but they certainly seem to be the loudest, and
>> hence, like right-wing "Christian" nuts vs. quiet and devout church-
>> goers, end up representing the entire community in the eyes of the
>> public.
> 
> A good analogy :-)
> 
>> When Ada came out it was touted as being almost magically self-correcting
>> and naturally platform independent.  It was the platform independence, in
>> fact, which was a large part of the reason that the DoD started insisting
>> on it.  Then, about a decade later, it came out that nearly all of the
>> installed Ada code base was, in fact, highly dependent on the hardware
>> for which it was written,
> 
> Isn't that natural for embedded systems interacting with specific
> hardware and peripherals? Even for non-embedded systems on mainframes,
> at that time the more advanced OS services were often system-specific
> and easily made applications non-portable.
> 

True.  At at that time, compilers were not as good as they are now - if
you wanted efficient code, you generally had to write a lot more in a
system-specific manner.

> I believe that Ada supports portability better than C (assuming
> compilers exist...), but it is also easy to write unportable Ada.
> Portability takes an effort, less in Ada than in C, but still.

I don't see Ada and C's portability being significantly different (at
least not after C99 with the <stdint.h> types).  It is mainly a matter
of how the programmer structures the code.

> 
>> and that -- astonishingly enough -- at times it
>> seemed that the software designers had gone out of their way to make the
>> code that they were writing only work on the hardware that their company
>> was selling.
> 
> "Customer capture"... not limited to Ada, nor even to software...
> 
>> It was a prime example of my argument with the more simple-minded members
>> of the "Ada is better" camp -- Ada may make it marginally _easier_ to
>> write better code.  However, if you want good, robust, portable code you
>> have to make it happen.  There is no magic language that'll make it
>> happen -- only language-independent diligence and hard work.
> 
> Agreed, except that to me the difference is more than marginal.
> 

On 23/09/15 23:03, Niklas Holsti wrote:
> On 15-09-23 10:11 , David Brown wrote:
> 
>> Here's a couple of "shoot yourself in the foot" jokes:
> 
> Here I go again, ruining a funny story by taking a factual view.
> 
> I enjoy satirical jokes about programming languages, but they must have
> some underlying truth in them.

The best ones have a ring of truth.

> 
> For example, I remember a comparison of programming langages with car
> models (sorry -- can't find a reference, I think it was in ACM SIGPLAN
> Notices long ago), in which Ada was compared to an army-green Mercedes,
> with no options as to colour or features, with the comment "if it is
> good enough for the generals, it is good enough for you". APL was
> compared to a bus, where lots of passengers can travel at once,
> organized into rows and columns (of seats). Both comparisons are founded
> in true points: the fact that Ada was very standardized (even
> trademarked), and had its roots in the military; and the fact that APL
> works on matrix data.
> 
> But the shoot-in-foot joke that you quote has no factual basis, or the
> factual basis cannot be turned into a joke that satirizes Ada.

I don't think these jokes are trying to be that clever - perhaps you are
over analysing them.  (However, it's good that this thread has someone
with strong Ada experience to comment.  My own experience is very
minimal - not much beyond "Hello, world!", and I read a book about
algorithms for language design that happened to use Ada as the main
implementation language.)

On 23/09/15 20:36, Simon Clubley wrote:
> On 2015-09-23, Tim Wescott <seemywebsite@myfooter.really> wrote:
>>
>> I believe the original paper is here:
>>
>> http://static1.1.sqspcdn.com/static/f/702523/9458053/1290008042427/200008-
>> McCormick.pdf
>>
>> (Thanks Jacob)
>>
> 
> Yes, I missed Jacob's original posting until I saw it quoted by you
> after I posted. :-(
> 
>> At least one of the points he noted about C makes me wonder if it isn't a 
>> biased instructor, rather than a bias between the languages, that was the 
>> primary cause of the problem.  The point was in a section of why Ada was 
>> better than C, and reads:
>>
>> "Representation clauses for device registers (record field selection 
>> rather than bit masks)"
>>
>> But, unless you're using a horribly obsolete version of C, you can use 
>> bit fields in structures.  And while this is, to some extent, excuse-
>> making, even with horribly obsolete versions of C you can damned well 
>> hide all of your bit mask ugliness inside of nice tidy macros.
>>
> 
> Good luck doing that in a reliable way on ARM with gcc when you are
> accessing device registers.
> 
> If you access a bitfield in the lower 8 bits of a register, the gcc
> optimiser can turn that into 8-bit ldrb/strb opcodes instead of 32-bit
> ldr/str opcodes and thereby causing the program to break if you need
> to access your registers in units of greater than 8 bits.
> 

That was fixed (bar any bugs in needlessly complex bitfield definitions)
in gcc 4.6, from 2011, with the "-fstrict-volatile-bitfields" option
that is on by default in ARM compilers.


> Ada's not immune as well if you try accessing the registers directly
> using bitfields; I helped someone out in comp.lang.ada a few weeks
> ago with a similar issue.
> 
> BTW, I've got a couple of Ada Issues open which talk about this and
> the related issue of directly updating multiple bitfields as one
> Read/Modify/Write operation instead of as multiple RMW operations.
> 
> It would be nice to be able to do that in C as well instead of having
> to use an intermediate variable (as you currently have to do with
> Ada as well).
> 
> Simon.
> 

Op Tue, 22 Sep 2015 22:18:57 +0200 schreef Niklas Holsti  
<niklas.holsti@tidorum.invalid>:
> On 15-09-22 20:40 , Tim Wescott wrote:
>> On Tue, 22 Sep 2015 08:53:28 +0200, David Brown wrote:
>>> On 21/09/15 19:24, Tim Wescott wrote:
>>>
>     [snip]
>
>> So I had to resort to intellectual violence: "hey, I know that I'm just  
>> a dumb-ass C programmer, and moreover that I'm Oregon born and bred. So  
>> could you Really Smart Ada people 'splain this here feature of your  
>> ever-so-wonderful language to me, in short words?"
>
> This part of your posting illustrates why I often find it difficult to  
> discuss Ada-vs-C with programmers who have used only C. Programmers are  
> proud of their knowledge and programs; if I suggest to a C user that I  
> believe there is a better language than C, they often seem to feel that  
> I'm calling them stupid, for having chosen a poorer language. Do you  
> have a suggestion for how I could avoid that misunderstanding?

What do you expect them to do?  Demote their existing programs (their  
"babies"), throw away their expert knowledge (sunk cost fallacy) and get  
out of their comfort zones?  I takes a bit of wisdom to handle these  
discussions.


-- 
(Remove the obvious prefix to reply privately.)
Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/

On 23/09/15 21:19, Tim Wescott wrote:
> On Wed, 23 Sep 2015 18:36:43 +0000, Simon Clubley wrote:
> 
>> On 2015-09-23, Tim Wescott <seemywebsite@myfooter.really> wrote:
>>>
>>> I believe the original paper is here:
>>>
>>> http://static1.1.sqspcdn.com/static/
> f/702523/9458053/1290008042427/200008-
>>> McCormick.pdf
>>>
>>> (Thanks Jacob)
>>>
>>>
>> Yes, I missed Jacob's original posting until I saw it quoted by you
>> after I posted. :-(
>>
>>> At least one of the points he noted about C makes me wonder if it isn't
>>> a biased instructor, rather than a bias between the languages, that was
>>> the primary cause of the problem.  The point was in a section of why
>>> Ada was better than C, and reads:
>>>
>>> "Representation clauses for device registers (record field selection
>>> rather than bit masks)"
>>>
>>> But, unless you're using a horribly obsolete version of C, you can use
>>> bit fields in structures.  And while this is, to some extent, excuse-
>>> making, even with horribly obsolete versions of C you can damned well
>>> hide all of your bit mask ugliness inside of nice tidy macros.
>>>
>>>
>> Good luck doing that in a reliable way on ARM with gcc when you are
>> accessing device registers.
>>
>> If you access a bitfield in the lower 8 bits of a register, the gcc
>> optimiser can turn that into 8-bit ldrb/strb opcodes instead of 32-bit
>> ldr/str opcodes and thereby causing the program to break if you need to
>> access your registers in units of greater than 8 bits.
> 
> That's a very interesting comment, because that's basically How It Is 
> Done here, and I've had several years worth of success on both ST and TI/
> Luminary devices.  I'm not sure if that's because of the way I define my 
> bitfields (absolutely everything is defined as a struct of bitfields, 
> then a union of that struct and a 32-bit integer), or if I've been lucky, 
> or what.
> 
> So it looks like:
> 
> struct SPeriphRegisterBits
> {
>   unsigned int bit0       : 1;
>   unsigned int bits1_10   : 10;
>   unsigned int bit11      : 1;
>   unsigned int            : 16;
>   unsigned int bits28_31  : 4;
> };
> 
> union UPerihRegister
> {
>   struct SPeriphRegisterBits bits;
>   unsigned int               all;
> }

A few comments here.

Don't use "unsigned int" - use uint32_t.  Make it all absolutely clear
and fully specified.

You don't need to do this in two parts.  Put it altogether, using an
anonymous struct (this is a very common extension to C99, which has
existed in gcc since close to the dawn of time, and it is now part of C11).

I prefer to make typedefs of all my types, so that I don't need union or
struct tags later.  But that is a matter of style.  And I strongly
dislike systems Hungarian style, such as prefixing a type with U just
because it happens to be a union (especially if you haven't used
typedef, so that you have to have the "union" tag too).

Make your padding bits explicit with a name.  The C++ memory model says
that unnamed fields may not be changed by any write operations (C is
more lenient), which can cause trouble for fields.  It's better to make
all your padding explicit.

I also like to add a static assertion to check that there are no
mistakes when defining structures like these.  Of preference I also use
"-Wpadded" in gcc to warn of any unexpected padding - but that does not
play well with most manufacturer-supplied headers.

typedef union {
	struct {
		uint32_t bit0 : 1;
		uint32_t bits1_10 : 10;
		uint32_t bit11 : 1;
		uint32_t padding : 16;
		uint32_t bits28_31 : 4;
	};
	uint32_t all;
} periphRegister_t;

static_assert(sizeof(periphRegister_t) == 4,
		"Check bitfield definition for PeriphRegister");


Having said all that, your definition will also work correctly (assuming
you've got the volatile there somewhere, and are using gcc 4.6 or above
which fixes the volatile bitfield problem).

> 
> All of the various register definitions then get collected into a 
> structure for the peripheral, which gets declared as "extern const", and 
> defined in the linker command file.

I presume you mean "extern volatile const", and that's only for the
read-only registers.  It's common to define registers like this:

#define periphRegister (*((volatile periphRegister_t*) 0x12345678))

(Registers can, of course, be collected in larger structures first.)

The advantage of that is that everything is defined in a C header file -
you don't need to mess around with linker files too.  And since the
compiler knows exactly what addresses are used, it can generate more
efficient code than if they have to be sorted out at link time.

> 
>> Ada's not immune as well if you try accessing the registers directly
>> using bitfields; I helped someone out in comp.lang.ada a few weeks ago
>> with a similar issue.
>>
>> BTW, I've got a couple of Ada Issues open which talk about this and the
>> related issue of directly updating multiple bitfields as one
>> Read/Modify/Write operation instead of as multiple RMW operations.
>>
>> It would be nice to be able to do that in C as well instead of having to
>> use an intermediate variable (as you currently have to do with Ada as
>> well).
> 
> It would probably require another built-in optimizer directive, like 
> "volatile".

If you write:

void test1(void) {
    periphRegister.bit0 = 1;
    periphRegister.bit11 = 0;
}

then the compiler will (correctly) generate two independent RMW
sequences, optimising only the calculations of the address to use.

If you want both assignments to be done in a single RMW operation, you
must do so explicitly - that's what the "all" field is for.

void test2(void) {
    periphRegister_t cache;
    cache.all = periphRegister.all;
    cache.bit0 = 1;
    cache.bit11 = 0;
    periphRegister.all = cache.all;
}


> 
> For that matter, unless you define your intermediate variable as 
> volatile, I could easily see a read/modify/write cycle that only modifies 
> the lower 8 bits come through as an 8-bit access.

No, it will not (assuming gcc with the volatile bitfield fix) - access
is always by the defined size.  However, the C standards do not say
anything about this, so compilers that do it differently (such as by
using a minimum access size) are not breaking the standards even if they
may be breaking the target's ABI.

> 
> Come to think of it (sorry for rambling, I'm just letting this stuff 
> dribble out my brain as it comes to me) that may be what I'm doing with 
> my elaborate struct -> union -> const struct construction.  Whatever I'm 
> doing, it works...
> 

The rambling is good - it is an excuse to discuss these things that can
be difficult to get write.  Hopefully lots of people will see these
posts, and maybe someone will learn something.  (And hopefully someone
will correct me if I've written anything incorrect!)

On 23/09/15 21:36, Hans-Bernhard Bröker wrote:
> Am 23.09.2015 um 20:08 schrieb Tim Wescott:
>> "Representation clauses for device registers (record field selection
>> rather than bit masks)"
>>
>> But, unless you're using a horribly obsolete version of C, you can use
>> bit fields in structures.
> 
> Yes, you can.  But unless you're also in charge of configuring or
> designing the C compiler for them to be used on, you can't rely on any
> particular mapping between the bit fields in a C struct and their
> physical address layout.  That's because just about every single aspect
> of that mapping is implementation-defined (or worse).  I.e. they're
> close to 100% unportable from one platform to the next.  Even just
> flipping a single switch on the same compiler can completely jumble the
> entire, carefully tuned data layout.
> 
> Now that's not too bad for a micro controller's internal registers,
> because data structure definitions for those will most likely be
> supplied by the compiler makers themselves, anyway.  Or if they're
> supplied by the chip maker, there'll be some ABI specification they
> enforce, which ties down all the loose ends.
> 
> But it is indeed quite bad concerning predefined data structures
> external to the CPU.  Even some relatively experienced C programmers
> will believe they should use C structs and bit fields to write a  driver
> module for an external device or, even more commonly, implement a
> communication protocol.  Well, that won't work.  And by the time they
> realize it, they will be so convinced of their original decision's
> correctness by "proof in the field", that they won't even be able to
> _see_ their error.

A key issue with bitfields is that there is no way in C to find out or
specify the ordering - LSB first or last.  There is also no
correspondence between bitfield ordering and the target endianness.
(There is also no standard way to find that out either, though typically
compilers have predefined macros for the purpose so that you can write
"#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN___" .)

For some platforms, there is no standard for bit ordering.  In
particular, on x86 there is no standard - and different compilers use
different orders (though LSB first is most common).  Famously, MS
changed the order from MSB first to LSB first on a point upgrade of
their C compiler - that caused much wailing and gnashing of teeth.

However, on other platforms, the ABI is much clearer.  On little-endian
ARM, bit ordering is always LSB first.  (I don't know about big-endian
ARM.)  So you can rely on that across different ARM compilers.



> 
>> And while this is, to some extent, excuse- making, even with horribly
>> obsolete versions of C you can damned well hide all of your bit mask
>> ugliness inside of nice tidy macros.
> 
> Absolutely.
> 

Boudewijn Dijkstra wrote:
> Op Tue, 22 Sep 2015 22:18:57 +0200 schreef Niklas Holsti
> <niklas.holsti@tidorum.invalid>:
>> On 15-09-22 20:40 , Tim Wescott wrote:
>>> On Tue, 22 Sep 2015 08:53:28 +0200, David Brown wrote:
>>>> On 21/09/15 19:24, Tim Wescott wrote:
>>>>
>>     [snip]
>>
>>> So I had to resort to intellectual violence: "hey, I know that I'm
>>> just a dumb-ass C programmer, and moreover that I'm Oregon born and
>>> bred. So could you Really Smart Ada people 'splain this here feature
>>> of your ever-so-wonderful language to me, in short words?"
>>
>> This part of your posting illustrates why I often find it difficult to
>> discuss Ada-vs-C with programmers who have used only C. Programmers
>> are proud of their knowledge and programs; if I suggest to a C user
>> that I believe there is a better language than C, they often seem to
>> feel that I'm calling them stupid, for having chosen a poorer
>> language. Do you have a suggestion for how I could avoid that
>> misunderstanding?
>
> What do you expect them to do?  Demote their existing programs (their
> "babies"), throw away their expert knowledge (sunk cost fallacy) and get
> out of their comfort zones?  I takes a bit of wisdom to handle these
> discussions.
>
>

Changing languages has switching cost. At least when you're
at work, there's nothing fallacious about that. I've little doubt
that Ada is a "better" language; unfortunately, it's
still harder to obtain toolchains and use them than 'C'.

'C' is sort of a "lingua franca".  Ada is kind of an
esperanto.

-- 
Les Cargill

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

>> What target are you wanting?
>> 
> 
> Currently PIC32 and ARM bare metal. If some things I am currently
> doing with the PIC32 work out, then I am going to forget about the
> PIC18 and drop it from the list of MCUs I am interested in.

Yeah not tried earlier PIC's, I'd be surprised if they're in GCC.

GCC does have MIPS now that Ingres have taken it over.

> 
> The last time I looked at your work however, you were having real
> problems with things being fragile or simply breaking from gcc version
> to gcc version.
>
> I know about Brian's work with the MSP430 stuff and I've used AVR-Ada
> in the past.

My whole problem was that GNAT couldn't be built without hacking the
configure scripts up and basically breaking;  this is his Brian does it. As
of GCC 5 that is no longer the case, I've included the same patch in
free-Ada.

> Given that RTEMS supports Ada, I've been toying with the idea of
> doing a RTEMS port for PIC32 in the future and seeing if Ada will
> be usable on it.

You should be fine with PIC32.

Luke

Op 24-Sep-15 om 2:22 PM schreef Boudewijn Dijkstra:
> Op Tue, 22 Sep 2015 22:18:57 +0200 schreef Niklas Holsti
> <niklas.holsti@tidorum.invalid>:
>> On 15-09-22 20:40 , Tim Wescott wrote:
>>> On Tue, 22 Sep 2015 08:53:28 +0200, David Brown wrote:
>>>> On 21/09/15 19:24, Tim Wescott wrote:
>>>>
>>     [snip]
>>
>>> So I had to resort to intellectual violence: "hey, I know that I'm
>>> just a dumb-ass C programmer, and moreover that I'm Oregon born and
>>> bred. So could you Really Smart Ada people 'splain this here feature
>>> of your ever-so-wonderful language to me, in short words?"
>>
>> This part of your posting illustrates why I often find it difficult to
>> discuss Ada-vs-C with programmers who have used only C. Programmers
>> are proud of their knowledge and programs; if I suggest to a C user
>> that I believe there is a better language than C, they often seem to
>> feel that I'm calling them stupid, for having chosen a poorer
>> language. Do you have a suggestion for how I could avoid that
>> misunderstanding?

Choosing a language is not just about the language. It is also (and 
maybe even more) about the tool quality, price and support, about 
literature, training and school that is available, about the existing 
body of users of that language, and about your guess about how these 
factors will evolve in the future.

These factors are all hughly in favour of existing well established 
languages. A new language must either access a niche that existing 
languages left barren, or have enormous benefits over the existing 
languages.

So a programmer who chooses to base his career on C (or C++, or Python, 
C#, Java, ...) should do so nog just on the quality of the language, but 
also (and mybe even mainly) on the other factors I mentioned.

I think C as a language has HUGHE problems, and C++ copied most of them. 
Jet C++ is my favourite language.

blog about this subject: http://www.voti.nl/blog/?p=1

Wouter