Searching \ for '[PIC] Source boost V HiTech compilers for C use' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/microchip/languages.htm?key=c
Search entire site for: 'Source boost V HiTech compilers for C use'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Source boost V HiTech compilers for C use'
2009\05\23@080847 by James Salisbury

flavicon
face
Hi,
How do people find the Sourceboost compiler compared to HiTech? I
currently have Sourceboost which I use for some C projects, what
advantage does Hitech have?
Thanks
James

2009\05\23@082356 by Xiaofan Chen

face picon face
On Sat, May 23, 2009 at 8:08 PM, James Salisbury
<spam_OUTpiclistTakeThisOuTspamjsalisbury.clara.co.uk> wrote:
> Hi,
> How do people find the Sourceboost compiler compared to HiTech? I
> currently have Sourceboost which I use for some C projects, what
> advantage does Hitech have?

Never used Sourceboost. But the following is what people say
about HiTech.

1) Better ANSI conformance
2) Best in class code size
3) No 1 leader in the market of PIC12/16 compiler

Some other features or non-features
1) Free pro version with no code size limit, but the optimization
is said to be quite bad with the free version
2) Works under Linux and Mac OS X along with Windows
3) Integrated well with MPLAB
4) Free HiTide IDE based on Eclipse
5) Now part of Microchip, so presumably some better access
to new device and better finance support
6) Annual maintenance fee


--
Xiaofan http://mcuee.blogspot.com

2009\05\26@091912 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: .....piclist-bouncesKILLspamspam@spam@mit.edu [piclist-bouncesspamKILLspammit.edu] On
Behalf
{Quote hidden}

Optimisation is pretty much non-existent with the Lite version.  It
seems some people assume the free compiler has been designed to
deliberately emit very poor code, but in fact it's just the same as the
standard compiler with optimisation disabled.

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

2009\05\26@100818 by Isaac Marino Bavaresco

flavicon
face
Michael Rigby-Jones escreveu:
{Quote hidden}

Some time ago I posted here a quick analysis that show that the code
generated is weird, not just inneficient, the only possibility is it
being made on purpose.

Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

2009\05\26@111220 by William \Chops\ Westfield

face picon face

On May 26, 2009, at 7:01 AM, Isaac Marino Bavaresco wrote:

> Some time ago I posted here a quick analysis that show that the code
> generated is weird, not just inneficient, the only possibility is it
> being made on purpose.

Well, no, not really.  Or yes, but being "intentionally weird" and  
"intentionally bad" are not necessarily the same thing.  Back when I  
took the compiler class, it was pretty common practice to emit "pseudo-
code" that was 1) generic to many processor types, so that the "front  
end" of the compiler could stay constant regardless of target, and 2)  
designed not so much to be efficient in any way, but to be easily  
optimized using assorted standard optimization algorithms in the back  
end.  Having a compiler emit code like this through a zero-
optimization final code generator could indeed produce "weird" object  
code, without being "maliciously bad."

That doesn't mean I'd want to use such a compiler for anything...

BillW

2009\05\26@112542 by Michael Rigby-Jones

flavicon
face
> Michael Rigby-Jones escreveu:
> >
> > Optimisation is pretty much non-existent with the Lite version.  It
> > seems some people assume the free compiler has been designed to
> > deliberately emit very poor code, but in fact it's just the same as
the
> > standard compiler with optimisation disabled.
> >
> > Regards
> >
> > Mike

> {Original Message removed}

2009\05\26@133338 by Isaac Marino Bavaresco

flavicon
face
Michael Rigby-Jones escreveu:
>> Michael Rigby-Jones escreveu:
>>    
>>> Optimisation is pretty much non-existent with the Lite version.  It
>>> seems some people assume the free compiler has been designed to
>>> deliberately emit very poor code, but in fact it's just the same as
>>>      
> the
>  
>>> standard compiler with optimisation disabled.
>>>
>>> Regards
>>>
>>> Mike
>>>      
>
>  
>> {Original Message removed}

2009\05\27@113651 by Michael Rigby-Jones

flavicon
face


> -----Original Message-----
> From: KILLspampiclist-bouncesKILLspamspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu] On
Behalf
{Quote hidden}

I still don't think it's deliberate, most likely caused by the way the
new compilers work, with generation of intermediate P code as mentioned
by someone else.

FWIW the older compilers also produced some nonsense code for simple
expressions prior to optimisation, e.g. from one of my old projects
using PICC 8.05:


148:               if( TMR1IE && TMR1IF ) {
 0011    1683     BSF 0x3, 0x5
 0012    1303     BCF 0x3, 0x6
 0013    1C0C     BTFSS 0xc, 0
 0014    281B     GOTO 0x1b
 0015    2816     GOTO 0x16
 0016    1283     BCF 0x3, 0x5
 0017    1C0C     BTFSS 0xc, 0
 0018    281B     GOTO 0x1b
 0019    281A     GOTO 0x1a
 001A    281D     GOTO 0x1d
 001B    281C     GOTO 0x1c
 001C    289C     GOTO 0x9c

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

2009\05\27@131430 by Isaac Marino Bavaresco

flavicon
face
Michael Rigby-Jones escreveu:
{Quote hidden}

What can be less optimized than v = n -> movlw n/movwf v? Optimizations
may be: v = 0 -> clrf v; v = 1 -> clrf v/incf v,f, etc...

{Quote hidden}

Gotos are expected around code inside a if/else construct. When there is
no else and the optimization is off, then you may expect gotos to gotos,
worse if there are ifs inside ifs or elses. What code is inside the if?

This is a completely different type of optimization.

Just analyze the code for 'v = 0', in no conceivable way even a crap
compiler may output this code.

> Regards
>
> Mike
>  


Regards,

Isaac

__________________________________________________
Faça ligações para outros computadores com o novo Yahoo! Messenger
http://br.beta.messenger.yahoo.com/

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...