Is Hitech C deliberately slugging code in the free version..?

[Alan B. Pearce-2]

> Though for the code samples in the OP, it's not so much that
> optimisations are disabled, but that unoptimisations are enabled!

I think the problem in the original example given is that the compiler is
using generic assignment code that could be using any register as a source,
as well as the possibility of a literal (which is what the example does) and
then has all sorts of hooks in the code that later get optimised out if not
used. The problem is that because there is absolutely no optimisation then
the code looks real bad.

As this discussion shows, they would have got a lot more street cred if they
had included a basic level of optimisation (after all they already had the
code from previous versions of the compiler). After all, the free versions
of Microchips compilers do this (apparently).

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Michael Rigby-Jones-2]

 

> -----Original Message-----
> From: piclist-bounces@...
> [mailto:piclist-bounces@...] On Behalf Of Herbert Graf
> Sent: 07 July 2009 20:16
> To: Microcontroller discussion list - Public.
> Subject: RE: [PIC] Is Hitech C deliberately slugging code in
> thefree version..?
>
> On Tue, 2009-07-07 at 19:34 +0100, Michael Rigby-Jones wrote:
> > Do you also believe that HiTech's previous FREE compiler was
> > unacceptable because it only supported a very few devices and had
> > memory limits on most of them?
>
> Nope, since that's the way it had always been. People knew
> going in what the limitations were.
>
> > They are now simply offering an alternative FREE compiler that is
> > crippled in a different way.  How on earth is this 'not acceptable'?
>
> It isn't an alternative, it's a replacement. Yes, the old one
> is still available, but it's not going to be updated. Anyone
> familiar with compilers knows that a compiler that isn't
> receiving bug fixes is worse then useless, it WILL end up
> wasting your time.
>
> > Does someone currently have a gun pressed to you head
> forcing you to
> > use this particular free compiler?  It's apparently very acceptable
> > for a large number of users who can now use any PIC they
> want, albeit
> > with higher memory usage and slower execution times.
>
> I never said it wasn't useful.
>
> > Had you paid money for a compiler with this kind of performance I
> > could understand your attitude, but I am at a complete loss to
> > understand this outcry about a FREE product.
>
> My outcry is the "redefinition" of the product. Yes, they
> added something really nice, but they took a huge thing away,
> and DIDN'T TELL PEOPLE ABOUT IT. That's what "grinds my
> gears". If they said that all optimization was gone, that
> code that fit and ran at a certain speed with the old
> compiler would be significantly bigger and run much slower
> I'd be more understanding. They didn't: people had to figure
> that out by themselves. This tells me they KNEW it would
> upset people, so they hid it, hoping no-one would notice.

When you download the compiler, the web page has a table comparing the
features of Lite mode with Pro mode, which clearly shows which
optimisations are disabled (all of them except a few printf
optimisations).  Hardly typical behaviour for a company trying to hide
something is it?

There are a lot of people using this compiler, I guess it can't be as
useless or as upsetting to people as you seem to think.  I see the very
occaisional post on the support forum from people reaching the
limitations of the Lite compiler, either getting lower than expected
speeds when bit bashing various peripherals, or running out of memory on
smaller devices, generaly when trying to use floating point math and/or
formatted I/O functions.  However, assembly can still be used for speed
critical stuff if required and the compiler allows you to use the larger
PIC's with lots of peripherals, so bit bashing stuff can be avoided in
many cases, and you can use all of the memory in these parts.  This is
no different to the limited free versions of other tools, e.g. Eagle
where you are limited to a small PCB size with two layers.

Regarding the legacy compiler, it was based on the last version of the
previous compiler generation (prior to the OCG comilers), so it's quite
a mature compiler.  There are still many people using that version as
well so clearly it's not worse than useless.

Seems to me that unless HiTech give away a full compiler and free
support then you are never going to be happy with them.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Carl Denk-2]

Not an area where I have much expertise, but sounds like the original
compiler was poorly done, and a lots of patches call optimizers are
added. I would think a good compiler, would do a good job, based on
individual lines or small groups of lines like a loop of code, and the
optimizer would look at more of a macro view, to eliminate duplicate
instructions, etc., say where a value is already in a register.

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Wouter van Ooijen]

> Not an area where I have much expertise, but sounds like the original
> compiler was poorly done, and a lots of patches call optimizers are
> added. I would think a good compiler, would do a good job, based on
> individual lines or small groups of lines like a loop of code, and the
> optimizer would look at more of a macro view, to eliminate duplicate
> instructions, etc., say where a value is already in a register.

It is not your area of expertise, but you seem to expect that your
conclusions are valid?

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Michael Rigby-Jones-2]

 

> -----Original Message-----
> From: piclist-bounces@...
> [mailto:piclist-bounces@...] On Behalf Of Carl Denk
> Sent: 08 July 2009 13:46
> To: Microcontroller discussion list - Public.
> Subject: Re: Is Hitech C deliberately slugging code in the
> free version..?
>
> Not an area where I have much expertise, but sounds like the
> original compiler was poorly done, and a lots of patches call
> optimizers are added.

As someone else mentioned, HiTech cover a range of very different target
devices so compiler design is likely to biased towards ease of
targetting different architectures rather than efficient
pre-optimisation code generation of a single target familly.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Carl Denk-2]

More of an outsiders thoughts of a summary of the supposed experts, for
comment, that's why I noted up front my qualifications. :)
1: Should a compiler, do a reasonable job of generating code on a line
by line basis, or is this not expected if the targets are a mixed bag of
devices in a family?
2: When you specify a target device, should the compiler generate
different code, then for a different device? This is excluding hardware
specifics like ADC, EUARTS ,UARTS, etc. which I would assume be handled
correctly for the device.
3: Should the optimizer then take that code generated on a line by line
basis and improve it by eliminating duplicates, and unnecessary steps?

It appears numerous examples have been cited where the basic code
generated was less than optimal quality, and as pointed out code size
can be an issue, though I don't recall seeing actual numbers as to, how
much larger the code got.


Wouter van Ooijen wrote:

>> Not an area where I have much expertise, but sounds like the original
>> compiler was poorly done, and a lots of patches call optimizers are
>> added. I would think a good compiler, would do a good job, based on
>> individual lines or small groups of lines like a loop of code, and the
>> optimizer would look at more of a macro view, to eliminate duplicate
>> instructions, etc., say where a value is already in a register.
>>    
>
> It is not your area of expertise, but you seem to expect that your
> conclusions are valid?
>
>  

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Ricardo de Azambuja]

How to avoid C compilers problems?
- Write in assembly :D

[ ]s

---------------------------------
Ricardo de Azambuja


On Wed, Jul 8, 2009 at 11:37 AM, Carl Denk<cdenk@...> wrote:

> More of an outsiders thoughts of a summary of the supposed experts, for
> comment, that's why I noted up front my qualifications. :)
> 1: Should a compiler, do a reasonable job of generating code on a line
> by line basis, or is this not expected if the targets are a mixed bag of
> devices in a family?
> 2: When you specify a target device, should the compiler generate
> different code, then for a different device? This is excluding hardware
> specifics like ADC, EUARTS ,UARTS, etc. which I would assume be handled
> correctly for the device.
> 3: Should the optimizer then take that code generated on a line by line
> basis and improve it by eliminating duplicates, and unnecessary steps?
>
> It appears numerous examples have been cited where the basic code
> generated was less than optimal quality, and as pointed out code size
> can be an issue, though I don't recall seeing actual numbers as to, how
> much larger the code got.
>
>
> Wouter van Ooijen wrote:
>>> Not an area where I have much expertise, but sounds like the original
>>> compiler was poorly done, and a lots of patches call optimizers are
>>> added. I would think a good compiler, would do a good job, based on
>>> individual lines or small groups of lines like a loop of code, and the
>>> optimizer would look at more of a macro view, to eliminate duplicate
>>> instructions, etc., say where a value is already in a register.
>>>
>>
>> It is not your area of expertise, but you seem to expect that your
>> conclusions are valid?
>>
>>
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Wouter van Ooijen]

> More of an outsiders thoughts of a summary of the supposed experts, for
> comment, that's why I noted up front my qualifications. :)
> 1: Should a compiler, do a reasonable job of generating code on a line
> by line basis, or is this not expected if the targets are a mixed bag of
> devices in a family?

I see no reason why it should.

> 2: When you specify a target device, should the compiler generate
> different code, then for a different device? This is excluding hardware
> specifics like ADC, EUARTS ,UARTS, etc. which I would assume be handled
> correctly for the device.

If the devices are sufficiently different the code will be forced to be
different.

> 3: Should the optimizer then take that code generated on a line by line
> basis and improve it by eliminating duplicates, and unnecessary steps?

could, but not necessary

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Herbert Graf wrote:

> It isn't an alternative, it's a replacement. Yes, the old one is still
> available, ...

So there seems to be an alternative, no? :)

> ... but it's not going to be updated. Anyone familiar with compilers
> knows that a compiler that isn't receiving bug fixes is worse then
> useless, it WILL end up wasting your time.

FWIW, I've been working with this line of compilers (paid license) since
1997 or so. In the first few years I remember finding the odd bug, but
for the last few years it's been quite stable. I didn't upgrade to their
new line of "Pro" compilers, and I also didn't update my compiler for a
while now, so I'm in a situation that's not that different from using
this free compiler -- and it hasn't wasted my time so far. I'm compiling
some rather complex projects with it.

> My outcry is the "redefinition" of the product. Yes, they added
> something really nice, but they took a huge thing away, and DIDN'T
> TELL PEOPLE ABOUT IT.

What do you mean by "didn't tell"? It seems they published the fact.

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Gerhard Fiedler]

Dario Greggio wrote:

> Chris McSweeny ha scritto:
>> On Mon, Jul 6, 2009 at 12:30 PM, Michael
>> Rigby-Jones<Michael.Rigby-Jones@...> wrote:
>>> The description of Lite mode on the HiTech website clearly states
>>> optimisations are disabled.
>>
>> Though for the code samples in the OP, it's not so much that
>> optimisations are disabled, but that unoptimisations are enabled! It
>> looks like rather than not including stuff they've actually gone to
>> some effort to make the free one worse. e free version and never
>> bother to download the demo.
>
> Hmmm, me and others have already pointed out that what we are seeing
> now is "possibly" the raw output of the compiler , "unoptimized" .

You really want to spoil the fun? :)

Gerhard
--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[SME-2]

>> Almost, but not quite.  Are you suggesting they should give away a
>> compiler that has no restrictions whatsoever?

Zilog gave away a C compiler with their SDks that they had to pay a
fee to the software provider for for each one that was registered.

They also sold true ICE's at utter bargain basement prices for what they did.

The processors were also bearably good.

Shame about the support and reaction to reported repeatable documented bugs.

According to what I read recently, with defections of development
staff to form other spinoffs they no longer have enough qualified
design staff to produce new silicon. Whether this is true I don't
know. (Defection to form spinoffs is a part of Zilog's origins so if
it also proves to be their demise it will be poetic). (Their website
doen't seem to suggest they are in any way moribund -
http://www.zilog.com )

> Actually, I would say yes. I have never understood companies who
> expect customers to buy, for a few hundred USD, a tool which simply
> makes it easier for that same customer to buy more product.

Zilog's approach seemed truly enlightened. They also did (do?) good
seminars. Shame about the background support when the going got really
tough).



        R

--
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist