"Jon Kirwan" <jonk@infinitefactors.org> wrote in message
news:0kvr675v0742e33ro46l71j1vomi3u8ivl@4ax.com...
> On Mon, 12 Sep 2011 11:10:56 +0200, David Brown
> <david@westcontrol.removethisbit.com> wrote:
>
>>On 12/09/2011 09:44, Arlet Ottens wrote:
>>> On 09/12/2011 09:31 AM, Tim wrote:
>>>> On Mon, 12 Sep 2011 09:16:27 +0200, Arlet Ottens wrote:
>>>>
>>>>>> I need to used this in the following calculation where "Data" is the
>>>>>> 14
>>>>>> bit raw sensor data consisting of Data[0]*16 + Data[1]:
>>>>>
>>>>> You probably mean Data[0] * 256 + Data[1] instead, or (Data[0]<< 8) +
>>>>> Data[1], if your compiler isn't smart enough.
>>>>>
>>>> C18 may not automatically cast to integer type for the computation, so
>>>> it's best to force it to be explicit:
>>>
>>> According to the user guide, if you use the -Oi command line option, the
>>> C18 compiler will follow standard integer promotion rules. For a novice
>>> programmer, I'd recommend enabling this option.
>>>
>>> I think Microchip should have made that the default, and implemented a
>>> command line option to deviate from the standard, or made their compiler
>>> smart enough to recognize where this optimization would be safe.
>>
>>Why do some manufacturers provide these pseudo-C compilers that don't
>>follow fundamental C standards? I can understand why a toolchain writer
>>might want to provide the option of something that lets you generate
>>smaller or faster code than you can get with a full C standard
>>implementation - but it must be a non-default option that the user
>>explicitly picks, and it must be something that actually makes sense
>>(integer promotion rules may /look/ like they produce worst code on an
>>8-bit machine, but that's only if the optimiser is not good enough).
>>
>> From this post it sounds like C18 is broken-by-design, and a trap for
>>the unwary - novices and experts alike. It's like TI's Code Composer
>>and their stupid "don't zero the bss" startup code.
>
> I used Microchip's C18's version 1.0 c compiler -- still have
> a number of editions from that era floating about here. I
> also had many chances to talk to one of the authors on the
> phone and actually meet him when he flew out here on vacation
> for a week.
>
> I have my own very limited perspective through which I 'see'
> this. So keep in mind it may not be 'truth,' but just a
> distorted view of a piece of it. And there are a few viewers
> here who know a LOT MORE about it than I do because they were
> also developing such compilers long ago, too. And know a lot
> more than I do. Maybe they will provide some better context.
>
> The general class of compiler at that time came out of the
> PIC16 and PIC17 era. I'm not sure if anyone these days
> remembers the PIC17 much or the PIC16C54, C55, C56, and C57
> of that time. I used all of them in EPROM and OTP form, in
> the late '80s and beyond. (And Microchip still makes the
> darned things. One of Microchip's defining features is to
> support products, long term.)
>
> Early on, and I can't remember when I first started using
> their c compiler but I think it would have been in the early
> '90s, the same compiler supported these early chips with a
> two-level hardware stack, as little as 512 instruction words
> and not that much more on the high end, plus a massive 24
> bytes of sram, and a W register.
>
> It wasn't an easy target and my guess is that they focused on
> getting something working. It's possible, though I've no
> specific memory of it anymore, that the first edition of
> their c compiler predates the 1990 c standard. If not, it
> wasn't too long after it. And there were many things that
> needed doing which were difficult to do or "too expensive" to
> do when talking about a target with 24 bytes of sram and a
> two level hardware stack (inaccessible, as well) for a PC.
>
> The usual integral promotion stuff, such as widening 'char'
> parameters to functions into 'int', would actually make
> customers _MORE_ angry, than less so, and would likely turn a
> program that _might_ fit into one that wouldn't have any
> chance at all and would force another choice.
>
> This was a very early time in the ownership period for the
> new venture capitalists who bought up the old IP and made the
> decision to compete very differently as Arizona MicroChip
> Technology and enter into the embedded control market. It's
> likely that they would have lost potential wins at this
> critical juncture if they had directed their compiler
> developers to stand on some formal c-pedestal. It was about
> taking what they had at the time, one FAB in Chandler, AZ,
> and making some tricky balancing decisions about combining
> EPROM with a very old cpu design and putting together docs
> and tools and various promotional materials; and knowing that
> perhaps the one other thing they could mix in was to support
> what they made and ensure end users would succeed rather than
> fail in their own product efforts. I'm guessing, but part of
> that focus sifted down to the developer group, as well, and
> held their own focus on a c compiler that would at the very
> least enable the widest possible range of minimalist
> applications to succeed. And this, I would further guess,
> meant not necessarily following integer promotions -- most
> especially "as a default." Because they couldn't be sure
> that customers' programmers would all be the smartest and
> most talented from operating system hosted crowd, but instead
> more likely just electronic design engineers who know about
> latches and registers and so on and would "think that way"
> about what they were coding.
>
> I want you to also keep in mind that the times here were very
> different in another way, which is why I bring up "electronic
> design engineers" in this context. Designers, at that time,
> were _less often_ familiar with coding. Many of them _then_
> had little or no experience there. Today, of course, it's
> almost a requirement -- to have at least some basic
> capability there. But back then, fewer did. They had their
> hands full enough with existing design issues and often
> shuffled the programming load onto coders.
>
> Also, microcontrollers without bus systems externally were a
> kind of new deal. Prior to about 1985 or so, and say with
> the 8031/32 core, one would design a system with external
> EPROM and SRAM along with the big cpu with lots of pins. To
> add a micro meant adding a lot of chips and taking up a lot
> of space. Once Microchip came into the market (and one or
> two others around that period), they were cast out as self
> contained systems without external buses -- but with I/O pins
> with specialized functions and everything else needed for
> small applications contained inside the chip. And this
> opened the door for a whole new set of cost and size
> constrained application spaces. For example, thermometers.
>
> Imagine a hardware engineer who has carefully looked at the
> hardware details of the PIC16C54, determined that the
> thresholds and drive capabilities of the I/O are acceptable,
> that the number of I/O pins match the need, and that 25 bytes
> of sram is more than enough for the concept. Package size is
> right, cost is right, etc. Using it will give them "an edge"
> over the competition.
>
> And now imagine some c compiler, which if it had chosen to
> follow the c standard by default (defaults and possible
> overrides about which the poor engineer wouldn't know much
> about because they were, almost by definition, relatively
> ignorant of programming issues like this back then) would
> cause the 25 bytes to become exceeded with various integer
> promotions "by rule."
>
> Now imagine that Microchip made the decision to set up the
> defaults so that the c compiler uses the least amount of sram
> possible -- doesn't promote 'char' to 'int' in parameter
> passing, for example. The engineer succeeds without even
> knowing why. But succeeds per plan. The c compiler didn't
> dictate rules poorly understood or cared about. It just
> worked as expected.
>
> It is the difference between a design win and success -- and
> there is no doubt about Microchip's success, in hindsight --
> and furious customers with expensive lessons learned but no
> products using microchip controllers.
>
> Standing on ceremony, at that time, would have been unwise.
>
> I guess I'm not all that bothered. We are talking about 8
> bit cpus, some of them, with as close to zero resources as it
> is possible to have and still have a microcontroller worthy
> of the name. If this were resource-rich 32-bit cpus? Yes.
> I'd be all over it. But I guess I don't see this from a
> Marie Antoinette "Why don't they just eat the cakes if they
> don't have any more bread left on the table?" point of view.
>
> Perhaps because I remember being on the other end of such
> pious views and in the trenches with nothing much to 'eat'
> and glad that there was a c compiler, at all. I didn't gnash
> my teeth because it didn't fit some standards org's idea of
> 'proper.' I was just glad to have any meal, at all.
>
> Jon
Thats an interesting read Jon, Thanks. I also started out playing with the
16C55 windowed EPROM devices. Only I didnt progress past assembler until
very recently. My crash & burn software development took quite a while
waiting for the UV eraser to do its thing.
Cheers.