Searching \ for 'PIC "C" Compilers......' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'PIC "C" Compilers......'.

Truncated match.
PICList Thread
'PIC "C" Compilers......'
1997\09\29@083444 by John Walker

flavicon
face
  I have for the past several weeks been developing some simple programs
under the MPLAB-C development environment. However, I now have a project that
will violate the 256 lines of code restrictions placed on the demo version of
MPLAB. While I wish I could afford to purchase the full version of the
software, I cannot, I am now looking for alternative "C" compilers. I have
been looking at the PCM compiler supplied by Custom Computer Services, Inc. I
was hoping to get some feedback from current users. If you are currently using
this product, or know of a similiar one with equivelant features, I would
greatly appreciate your feedback. While I am running the software on a PC
platform, I don't have a preference for Windows or DOS based applications.
Thanks in advance for any responses.

1997\09\29@093821 by Andy Kunz

flavicon
face
>been looking at the PCM compiler supplied by Custom Computer Services, Inc. I

I used it for several months and was rather frustrated.

I now use the HiTech C compiler and I am VERY HAPPY!

Andy



==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\09\29@094553 by unthiti Patchararungruang

flavicon
face
On Mon, 29 Sep 1997, John Walker wrote:

>    I have for the past several weeks been developing some simple programs
> under the MPLAB-C development environment. However, I now have a project that
> will violate the 256 lines of code restrictions placed on the demo version of
> MPLAB. While I wish I could afford to purchase the full version of the
> software, I cannot, I am now looking for alternative "C" compilers. I have
> been looking at the PCM compiler supplied by Custom Computer Services, Inc. I
> was hoping to get some feedback from current users. If you are currently using
> this product, or know of a similiar one with equivelant features, I would
> greatly appreciate your feedback. While I am running the software on a PC
> platform, I don't have a preference for Windows or DOS based applications.
> Thanks in advance for any responses.
>

Why you didn't try Hi-tech C Compiler. The demo version can support your
code. You can download it from http://www.htsoft.com/pic/. I think you
will like it.

Sunthiti Patchararungruang

1997\09\29@103602 by John Payson

picon face
>    I have for the past several weeks been developing some simple programs
> under the MPLAB-C development environment. However, I now have a project that
> will violate the 256 lines of code restrictions placed on the demo version of
> MPLAB. While I wish I could afford to purchase the full version of the
> software, I cannot, I am now looking for alternative "C" compilers. I have
> been looking at the PCM compiler supplied by Custom Computer Services, Inc. I
> was hoping to get some feedback from current users.

A year or so ago, the CCS compiler was a bit buggy; by now its support for
one and two-byte unsigned integers and all the normal maths with them is
stable; it has support for signed and floating-point maths too now, but I've
not used those features yet.

As for Hitech, it looks like a good compiler.  It does cost more than PCM,
but it supports additional features such as "long"s that are 32-bits (I
wish CCS did, but it doesn't), etc.  On the other hand, its library of built-
in I/O is from what I've heard a bit limitted (on the CCS compiler, if you
tell it what pins and baud-rate you want for a bit-bang port, you can use
"printf"s just be writing them).

Anyway, I don't know your exact budget, but I know I've gotten a lot of use
from the CCS compiler; Hitech looks like it may be a better product, but I
don't know whether it would be worth the extra cost.

1997\09\29@132601 by Micheal Yano

flavicon
face
I've been using the PCB and PCM compilers for about a year, I have had one
problem with the 16C62X comparators, but it was fixed by CCS in a day. For
the cost and support $99.00 each, I don't think you can beat it.

At 08:28 AM 9/29/97 EDT, you wrote:
{Quote hidden}

Thanks.


****************************************************
    __           Micheal Yano
   ----          Internet:     spam_OUTmyanoTakeThisOuTspamcimtek.on.ca
 -CIMTEK-        IBMMAIL:      .....i1320285KILLspamspam@spam@IBMMAIL.COM
------------      Voice:        (905)847-8811 x22
                   FAX:        (905)847-8822
****************************************************

1997\09\29@133543 by Jim Dolson

picon face
John Walker wrote:
>
>    I have for the past several weeks been developing some simple programs
> under the MPLAB-C development environment. However, I now have a project that
> will violate the 256 lines of code restrictions placed on the demo version of
> MPLAB. While I wish I could afford to purchase the full version of the
> software, I cannot, I am now looking for alternative "C" compilers. I have
> been looking at the PCM compiler supplied by Custom Computer Services, Inc. I
> was hoping to get some feedback from current users. If you are currently using
> this product, or know of a similiar one with equivelant features, I would
> greatly appreciate your feedback. While I am running the software on a PC
> platform, I don't have a preference for Windows or DOS based applications.
> Thanks in advance for any responses.

John,

I have no financial interest in CCS and don't know the guy.  Having said
that ...

I had an idea for a project which would use a PIC four weeks ago.  I had
never worked with a PIC before, although I have an electronics and
programming background.  Designing the circuit was not too difficult,
but I knew that learning the assembler for the PIC and doing the
programming would take months.

I came across the CCS PCM compiler and thought for $95 it was worth a
try, but I just knew that the code size would balloon up and I'd have to
go back to assembler.

Well, I am absolutely delighted with the compiler.  It is so much faster
programming in C, the libraries that CCS have are excellent, and the one
tech support e-mail I sent was answered within 24 hours.  I am a very
satisfied customer.  It has allowed me to (just about) finish a
non-trivial project in weeks instead of months.

The only odd thing is that if you want support beyond the first 30 days,
it costs $95/year.  I'm debating whether to get it or not.  The current
version has not caused me any problems yet.

Jim Dolson
jdolsonspamKILLspamiserv.net

1997\09\29@152632 by Andy Kunz

flavicon
face
>Anyway, I don't know your exact budget, but I know I've gotten a lot of use
>from the CCS compiler; Hitech looks like it may be a better product, but I
>don't know whether it would be worth the extra cost.

I look at the great cost savings in time by not having to check the
generated assembly code (a necessity with CCS) as the major offset to the
cost of using HiTech (which, when I bought it, was actually cheaper than
CCS).  The CCS stuff, as others have pointed out, does support more
peripherals with macro code, but I already have most of them in assembly
anyway, so it doesn't matter.

The HiTech code is clean, efficient, and very predictable.  The CCS code
was usually rather obtuse.

The HiTech allows linking of modules into the final product, and has all
the features a _real_ C system needs:  multiple output steps of code (ie,
you can get a .PRE output, a .AS output, .OBJ, etc. up to a .HEX), a
standalone assembler, & linker.  Basically, it's a REAL product.  It also
comes with eons of experience with the Avocet line, which I use for other
processors, and I get to use the same flavor everywhere.  Only real
downside is the lack of a Windows IDE.

The printf() function works in HiTech as well.  You simply need to define
your own putc () and you're in business.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\09\29@155300 by Jim Dolson

picon face
Please don't take offense, but I see a good product that works for me
getting trashed, so ...

Andy Kunz wrote:

> I look at the great cost savings in time by not having to check the
> generated assembly code (a necessity with CCS) as the major offset to the
> cost of using HiTech (which, when I bought it, was actually cheaper than
> CCS).

1. I look at the great cost savings in spending $100 instead of $700 on
products which, for my needs, are equivalent.  Also,

2. I've never checked the generated assembly code and my application
runs just fine.  Of course, not knowing PIC assembler is one reason why
I haven't checked it.  I see no need.  I know C and I know that my
application runs.

> The HiTech code is clean, efficient, and very predictable.  The CCS code
> was usually rather obtuse.

I code with CCS because I have a product to get out, not because it
generates beutiful assembler.  My customers could care less what the
code looks like.  They want the application to work.

> The HiTech allows linking of modules into the final product, and has all
> the features a _real_ C system needs:  multiple output steps of code (ie,
> you can get a .PRE output, a .AS output, .OBJ, etc. up to a .HEX), a
> standalone assembler, & linker.  Basically, it's a REAL product.

Gee, you mean that I haven't been programming with a REAL product?  I
guess that I should throw away a nearly completed product and spend
seven times what I spent for CCS just so that I can work with a 'REAL'
compiler?

Sorry for the sarcasm Andy, but we don't all have unlimited budgets.  If
something works, and it is inexpensive, I'll buy it.  I don't need a ton
of bells and whistles which, for me at least, are completely useless
features.  Why pay for something that most (?) people will never use?

Jim Dolson
.....jdolsonKILLspamspam.....iserv.net

1997\09\29@160050 by trogers

flavicon
face
Andy Kunz wrote:

> I look at the great cost savings in time by not having to check the
> generated assembly code (a necessity with CCS) as the major offset to the
> cost of using HiTech (which, when I bought it, was actually cheaper than
> CCS).  The CCS stuff, as others have pointed out, does support more
> peripherals with macro code, but I already have most of them in assembly
> anyway, so it doesn't matter.

Andy, you shouldn't mislead the guy: most people I know check the output of any
compiler used in an embedded system. Its good practice to know how the compiler
is dealing with your project, and it doesn't take a lot of time once you scope
out the usual oddities. There's too many ways to screw up an embedded system
with any high level language; even with big mini based stuff, I always wanted to
see how the low level bits came out. I don't mean to say that you should walk
through the floating point, for example, but I do expect that the guy that wrote
the library did. AND, on PIC projects there's always something at the low end
that you wrote, or caused to be linked in a particular way.

Always check the output of a project as a matter of principle. Especially if it
seems to be working.

--Tom Rogers  VP-R&D  Time Tech Inc.

1997\09\29@190836 by Andy Kunz

flavicon
face
>1. I look at the great cost savings in spending $100 instead of $700 on
>products which, for my needs, are equivalent.  Also,

I make my living doing this.  $600 is a day's pay at my full rate.  I have
easily saved that several times over by upgrading to HiTech.

>2. I've never checked the generated assembly code and my application
>runs just fine.  Of course, not knowing PIC assembler is one reason why
>I haven't checked it.  I see no need.  I know C and I know that my
>application runs.

Maybe, because of the nature of the programming I do, it is essential that
the compiler be trusted to generate code which accomplishes the desired
operation.

>> The HiTech code is clean, efficient, and very predictable.  The CCS code
>> was usually rather obtuse.
>
>I code with CCS because I have a product to get out, not because it
>generates beutiful assembler.  My customers could care less what the
>code looks like.  They want the application to work.

I don't look for beautiful assembler, either.  But I do like code that is
easy enough to verify.  Which gets right to YOUR point - "they want the
application to work."

I bought the CCS compiler hoping I would save time.  In fact, I lost time
for most things.  Several times it was so bad I ended up recoding the
entire project in assembly, because I CAN trust the assemblers (Parallax
and Microchip, at that time).

Since converting to the HiTech C, I've only found a few problems, all of
which have been addressed or have suitable workarounds.

>Gee, you mean that I haven't been programming with a REAL product?  I
>guess that I should throw away a nearly completed product and spend
>seven times what I spent for CCS just so that I can work with a 'REAL'
>compiler?

Only if you need to be able to use a linker, a librarian, and mix C and
assembly routines at will (without knowing which is which).

>Sorry for the sarcasm Andy, but we don't all have unlimited budgets.  If

Nor do I.

>something works, and it is inexpensive, I'll buy it.  I don't need a ton
>of bells and whistles which, for me at least, are completely useless
>features.  Why pay for something that most (?) people will never use?

Well, for ME these are features I would put either on the "darn tootin'
nice to have" or "gotta have, can't do without" lists.

But the best point is your first one - customers want the apps that work.
That's the difference between the two products.

Here's what I mean:

I owned the CCS compiler for ~5-6 months.  During that time I was able to
complete 1 project with it for shipment (and to do so I had to write my own
PRINTF function in assembly because CCS didn't yet support 16-bit values in
PRINTF).  Since late August (I got one of the initial releases of HiTech's
compiler) I have delivered 3 projects using HiTech.

I have since gone back and changed the other app into HiTech code.  No
assembly was required.  What else can I say.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\09\30@024501 by mikesmith_ozNOSP*M

flavicon
face
On 29 Sep 97 at 19:03, Andy Kunz wrote:

<big snip>

{Quote hidden}

Here's a real quick question which hasn't been touched - when you
re-compiled the CCS app into HiTech, which was most space-efficient,
and could you give an idea of the relative sizes? (rom & ram)  I've
seen some reasonable '1 page' code/ram apps blow way out when you
exceed one page.
MikeS
<mikesmith_ozNOSP*M.relaymail.net>
(remove the you know what before replying)

1997\09\30@160209 by Andy Kunz

flavicon
face
Mike Smith wrote:

>Here's a real quick question which hasn't been touched - when you
>re-compiled the CCS app into HiTech, which was most space-efficient,
>and could you give an idea of the relative sizes? (rom & ram)  I've
>seen some reasonable '1 page' code/ram apps blow way out when you
>exceed one page.

Not that easy.  Since HiTech is a standard ANSI C and CCS isn't, it
required _major_ changes.

Why don't you send me a CCS program and I'll convert to HiTech and give you
the answer.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================


'PIC "C" Compilers......'
1997\10\06@160815 by Mark Hellman
picon face
I have a better idea, one of you guys with the Hi-Tech C write a simple
program for the '84' that reads one byte from a half duplex serial port,
echo's back the byte, writes the byte to I2C memory, reads the byte from
I2C memory, sends the byte. A simple test of something we all do on a
regular basis that tests common library support.

My CCS results : ~374 instructions
                (I don't remember exactly(+4-2), not so go in my book, typical
C bloat)
My ASM results: 208 instructions (MChip RS232 (few mods),My I2C,
respectable)
Hi-Tech ?
Others ?

I am normally more interested in getting the most features in the smallest
space. In this arena, ASM and the gray matter between your ears rule
supreme. Quick turn-around is achieved by cut-N-paste from code libraries.
When code size is no object, C, of course, is the easy way out. If I ever
get a project where this is the case I will buy Hi-Tech C (I love the
features, hate the price). For now, CCS works just fine for small quickie
type projects.

The true value of a C compiler in our world lies in the amount of time the
producer has spent optimizing the generated code. You can have all the
bells and whistles under the sun, but, if the program doesn't fit in the
part, what good is it? Likewise, if you have to down code a large portion
of your program to get it to fit, what have you gained? My other pet peeve
is that C functions normally don't have the options I need, like time-outs.
Nothing is more irritating than a built-in or library function that "waits
forever", if nothing is happening, I have better things to do, like SLEEP
(save the batteries!). The best C system I have worked with lately is
ZWorld Dynamic C, it's not ANSI, but it _IS_ highly optimized for what we
do, real-time systems programming.

Whew, I feel much better, sorry about the rambling.

Have a GREAT day,

Mark

{Original Message removed}

1997\10\06@222822 by Alan G. Smith

flavicon
face
Assuming, I understand correctly I get 257 words for the HI-TECH C (using my
own I2C stuff.)

Here is my main function, let me know if this isn't what it is supposed to do:
(Please excuse the lack of comments, I just whipped this up to see.)

void main( void )
{
  char ch;

  InitI2CBusMaster();
  for(;;){
     ch = getch();
     putch(ch);
     busControl.bits.slave_RW = WRITE;
     TxmtStartBit();
     TxmtSlaveAddr(0xA0);
     SendData(0x00);         // always write data to address location 0
     SendData(ch);
     TxmtStopBit();
     busControl.bits.slave_RW = READ;
     TxmtStartBit();
     TxmtSlaveAddr(0xA0);
     ch = GetData();
     TxmtStopBit();
     putch(ch);
  }
}



+---------------------------------------------------------
| Alan G. Smith
| EraseMEagsspam_OUTspamTakeThisOuTpoboxes.com
| http://www.innovatus.com/ags

{Original Message removed}

1997\10\07@083709 by John Payson

picon face
>
> I have a better idea, one of you guys with the Hi-Tech C write a simple
> program for the '84' that reads one byte from a half duplex serial port,
> echo's back the byte, writes the byte to I2C memory, reads the byte from
> I2C memory, sends the byte. A simple test of something we all do on a
> regular basis that tests common library support.
>
> My CCS results : ~374 instructions

If you look at CCS's code, their I2C routines are rather bloated.  I don't
know the exact reasoning behind some of the coding decisions (probably some
RAM/ROM tradeoffs involved) but while their RS232-style stuff is handy for
debugging sometimes I find their I2C stuff less useful (and instead spin
my own).

Note that this is not necessarily a slam at CCS; some I2C devices require
a more complex protocol that others.  For example, a "proper" I2C master
should float the clock wire after each bit (there must be a pullup on it)
and wait for it to go high; slower I2C devices that can't keep up with the
bit rate may hold the line low for up to something like 1ms/bit.  Since the
I2C memory devices can always keep up with any valid bit rate, a system that
ONLY has such memory devices on its I2C bus can simply drive the clock full
high/full low at whatever rate it wants.  This will simplify the code, but
will cause the code to fail on other devices.

Personally, I also usually write my I2C routines a bit differently from
CCS's: the write-byte routine assumes the current bit out there is an ack
from the previous write, clocks it out, then clocks 8 data bits.  After that
it checks the state of the data line (to see if there was an ACK) but it
does not clock out the ACK.  The read routine asserts data, clocks once,
releases data, and then clocks 8 data bits.  If another byte of data is
needed, the PIC can ACK it then.

This approach works well from my experience (a little trickery is required
to make the writes work with the start condition, but nothing too bad) and
is easier than declaring after each byte whether I'll want another.

Anyone else use this trick?

1997\10\08@144515 by Mark Hellman

picon face
Allen,

Thanks for the effort! Could you try it again using the supplied (Hi-Tech)
I2C lib? (I assume it comes with I2C support) My point was that for $800 I
expect vastly superior code to be generated _without_ resorting to down
coding in ASM. ANSI complience does _not_ justify the price they ask, nice
tight code generation close to ASM would (Major pipe dream!).

Have a GREAT day,

Mark

-----Original Message-----
From:   Alan G. Smith [SMTP:agsspamspam_OUTPOBOXES.COM]
Sent:   Monday, October 06, 1997 8:27 PM
To:     @spam@PICLISTKILLspamspamMITVMA.MIT.EDU
Subject:        Re: PIC "C" Compilers......

Assuming, I understand correctly I get 257 words for the HI-TECH C (using
my
own I2C stuff.)

1997\10\08@180637 by Alan G. Smith

flavicon
face
>Thanks for the effort! Could you try it again using the supplied (Hi-Tech)
>I2C lib? (I assume it comes with I2C support)
That would be an incorrect assumption.

> My point was that for $800 I
>expect vastly superior code to be generated _without_ resorting to down
>coding in ASM. ANSI compliance does _not_ justify the price they ask, nice
>tight code generation close to ASM would (Major pipe dream!).
My example was done fully in C (even my I2C stuff)

You can't expect a C compiler to do as well as you do in Assembler because you
know a lot of stuff
the compiler
doesn't.

--Alan


+---------------------------------------------------------
| Alan G. Smith
| KILLspamagsKILLspamspampoboxes.com
| http://www.innovatus.com/ags

1997\10\08@190041 by Pierce Nichols

flavicon
face
On Wed, 8 Oct 1997, Alan G. Smith wrote:

> You can't expect a C compiler to do as well as you do in Assembler because you
>  know a lot of stuff
> the compiler
> doesn't.

       Actually, on yr computer, gcc in optimize mode will compile
somewhat better asm code than you could hand-code.

       Pierce Nichols



1997\10\08@204504 by Andy Kunz
flavicon
face
At 06:58 PM 10/8/97 -0400, you wrote:
>On Wed, 8 Oct 1997, Alan G. Smith wrote:
>
>> You can't expect a C compiler to do as well as you do in Assembler
because you
>>  know a lot of stuff
>> the compiler
>> doesn't.
>
>        Actually, on yr computer, gcc in optimize mode will compile
>somewhat better asm code than you could hand-code.
>
>        Pierce Nichols

Pierce,

I own some excellent waterfront property in the Sahara.  Interested?

The definition of "best" varies from application to application, and only
the programmer knows what that might be, and to what extent.

<G>

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\10\09@013116 by Walter Banks

picon face
We regularily win with compiled C against hand written assembler. The
difference is the compiler doesn't foprget a programmers trick.

Walter Banks

>
> On Wed, 8 Oct 1997, Alan G. Smith wrote:
>
> > You can't expect a C compiler to do as well as you do in Assembler
because you
{Quote hidden}

1997\10\09@083933 by Alan G. Smith

flavicon
face
On Wed, 8 Oct 1997, Pierce Nichols wrote:

> On Wed, 8 Oct 1997, Alan G. Smith wrote:
>
> > You can't expect a C compiler to do as well as you do in Assembler because
you
> >  know a lot of stuff
> > the compiler
> > doesn't.
>
>         Actually, on yr computer, gcc in optimize mode will compile
> somewhat better asm code than you could hand-code.
>
>         Pierce Nichols
>
Perhaps better than *you* could hand-code. ;-)  However, given infinite
amounts of time, an intelligent engineer with a data manual can ALWAYS
beat a compiler.  The engineer simply has more information.

--Alan
+---------------
| Alan G. Smith
| RemoveMEagsTakeThisOuTspampoboxes.com
| http://www.innovatus.com/ags

1997\10\09@084150 by Alan G. Smith

flavicon
face
On Wed, 8 Oct 1997, Walter Banks wrote:

> We regularily win with compiled C against hand written assembler. The
> difference is the compiler doesn't foprget a programmers trick.
>
> Walter Banks
Yes, but after looking at your output and remembering the trick I can
write assembler code that will at least tie it and probably beat it.
(After all, I know more info than the compiler.)

Please don't misunderstand my posts.  I USE compilers and only go in and
write stuff in assembler that is time/space critical.  I would NEVER get
my work done if I didn't use these tools.  But we must not believe the lie
that the compiler is generating tighter/faster code than we could by hand.

--Alan

{Quote hidden}

1997\10\09@092346 by Clyde Smith-Stubbs

flavicon
face
On Thu, Oct 09, 1997 at 08:23:46AM -0400, Alan G. Smith wrote:
> But we must not believe the lie
> that the compiler is generating tighter/faster code than we could by hand.

The key here is the difference between "is generating" and "could by hand".

It's true that, given enough time, an assembler programmer can write code at
least as tight as a compiler can generate. It's also true that, given enough
time, a compiler writer can tweak a compiler to equal hand-written code for
any given example.

But in practice, there never is enough time. So for the bulk of the code
the compiler will generate better code than the programmer has time to
write, and a programmer may hand-optimize small bits of code the compiler didn't
quite do well enough.

There are also a few things compilers can do that an assembler programmer
would not dare. My favourite is the PDP-11 instruction that Dennis Ritchie's
compiler would produce for something like

       var = 2;

where var was a local variable, at an offset of 2 from the frame pointer. The
instruction generated was

       mov     (pc),2(r5)

which exploits the PDP-11's ability to use the PC as an index register,
so the constant 2 does double duty as the immediate value AND the
frame pointer offset.

Any assembler programmer who did anything like that for me would
be fired. It's unmaintainable, but it's ok for the compiler to do since
it will regenerate the code on each compilation, and if the offset and
constant no longer match, will do something else instead.

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: spamBeGoneclydespamBeGonespamhtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger TakeThisOuTclydeEraseMEspamspam_OUThtsoft.com   | AUS: +61 7 3354 2411 +61 7 3354 2422
---------------------------------------------------------------------------
ANSI C for the PIC! Now shipping! See http://www.htsoft.com for more info.

1997\10\09@095439 by terogers

flavicon
face
Mark Hellman wrote:

> Allen,
>
> Thanks for the effort! Could you try it again using the supplied (Hi-Tech)
> I2C lib? (I assume it comes with I2C support) My point was that for $800 I
> expect vastly superior code to be generated _without_ resorting to down
> coding in ASM. ANSI complience does _not_ justify the price they ask, nice
> tight code generation close to ASM would (Major pipe dream!).

If you really believe that the meeting the standard isn't worth that much, well,
then you are due for a pleasant surprise (or not, if you don't have it). There
are about 10 subtle things in the preprocessor (for example) that can make your
collection of general purpose routines a dream to use. When you find yourself
saying "So that's why they did that," then you're on the right track.

Remember, C has a world unto itself with a stranger obfuscated tradition than
these simple Microchip products. There was a time that a genuine C hacker could
do magic with the simplest code. That stuff isn't gone, or any less valuable;
it's just overshadowed by the current fascination with PC And Things PC. For all
of the simplicity of it's definition, C (and the preprocessor and the operating
environment hooks) is very carefully thought out. Ignoring any part of that (in
a compiler design) can lead to frustration, despair, and longer coffee breaks.

It isn't really about portability. It's about the way the tool really should be.

--Tom Rogers  VP-R&D  Time Tech Inc.

1997\10\09@095444 by terogers

flavicon
face
As good as maybe; not better, if I haven't been up all night.

--TR

Pierce Nichols wrote:

>         Actually, on yr computer, gcc in optimize mode will compile
> somewhat better asm code than you could hand-code.
>
>         Pierce Nichols

1997\10\09@115331 by Tom Handley

picon face
  Geesh, Pierce... I wanted to stay out of this but what you said is
simply not possible given an experienced assembler programmer. I use a
mix of low and high-level languages depending on the task at hand. For
the PIC, I use assembler though I am considering a C compiler but that
would relate to productivity and not the quality of code.

  - Tom

{Quote hidden}

1997\10\09@142313 by jorgegf

flavicon
face
Hi folks




Clyde Smith-Stubbs wrote:
>
> On Thu, Oct 09, 1997 at 08:23:46AM -0400, Alan G. Smith wrote:
...
{Quote hidden}

...

       Its a long way from PDP-11 to a PIC, don't you think.

...
>
> Any assembler programmer who did anything like that for me would
> be fired. It's unmaintainable, but it's ok for the compiler to do since
> it will regenerate the code on each compilation, and if the offset and
> constant no longer match, will do something else instead.
...

       So fire me ;-). I've doing such things since I can remenber, its a
matter of exploring the darkest aspects of your hardware (by the way
that sintax is very similar to ASM86 by Intel).
By the way compilers are made by programmers, aren't they, so I think
all this discussion as no point at all, because the code a compiler
generates can only be as good as the code that would be written by the
guys who make the compiler. And I bet you that those guys probably
learned some morer tricks from then until now, as we all did.


       best regards

       Jorge F

1997\10\09@192537 by Clyde Smith-Stubbs

flavicon
face
On Thu, Oct 09, 1997 at 06:14:27PM +0100, Jorge Ferreira wrote:

>         Its a long way from PDP-11 to a PIC, don't you think.

Nope, all processors have their little subtleties. That's just a nice
example that I trot out from time to time. I should probably come up
with one for the PIC, I guess.

>         So fire me ;-). I've doing such things since I can remenber, its a
> matter of exploring the darkest aspects of your hardware (by the way

The point is that using such tricks in hand-coded assembler greatly increases
the chances that later on you will change something that breaks your
clever optimization. A compiler on the other other hand rewrites the
assember code each time it compiles the source, so it can check
the validity of such clever tricks each time - you have to remember
to do it.

> By the way compilers are made by programmers, aren't they, so I think
> all this discussion as no point at all, because the code a compiler

Exactly my point; the limiting case of both hand-written and automatically
generated code is the same. It's just a matter of how much time you have
to spend to get there, and how much time you have to spend later
maintaining it. On a small project (say < 1K of code) it's not hard
to make a case for using assembler. As the project gets larger it gets
harder and harder to make that case. At some point the growing complexity
of the project makes it impossible to write in assembler (the time required
to write code grows exponentially with the size of the project).

It is true that a good compiler can routinely out-code an average assembler
programmer. The difference between an average programmer and a hot one is
an order of magnitude or so. Of course no-one on this list is merely average :-)

Cheers.

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: RemoveMEclydespamTakeThisOuThtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger clydeEraseMEspam.....htsoft.com   | AUS: +61 7 3354 2411 +61 7 3354 2422
---------------------------------------------------------------------------
ANSI C for the PIC! Now shipping! See http://www.htsoft.com for more info.

1997\10\09@200502 by William Chops Westfield

face picon face
Are we really having this debate again?

I think what it boils down to is that the tricks that allow a good assembly
programmer to outdo a compiler frequently become difficult and
unmaintainable as the size of the project increases.  Meanwhile, the tricks
that a compiler can use don't affect maintainabilty (as long as it does them
RIGHT), so it eventually pulls ahead.  In other words, as your program
becomes bigger, you'd be foolish not to implement some of the same things
that make compiled code slower (ie, a standard calling convention with
register saving), and equally foolish to implement some of the speedups
that a compiler can get away with.

I think even an average assembly programmer can outdo a compiler on a small
piece of code.  Usually, that's all that is necessary.

BillW

(and do you want to know how many magabytes of assembler I have that only
runs on unobtainium CPUs, and I'd dearly LOVE to have be more portable!)

1997\10\09@212531 by Mike Smith

flavicon
face
-----Original Message-----
From: Andy Kunz <EraseMEmontanaspamFAST.NET>
To: RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU <RemoveMEPICLISTspam_OUTspamKILLspamMITVMA.MIT.EDU>
Date: Thursday, 9 October 1997 10:16
Subject: Re: PIC "C" Compilers......


{Quote hidden}

If you supply it with cheap running water...

>
>The definition of "best" varies from application to application, and only
>the programmer knows what that might be, and to what extent.

For simple processors like the PIC, code efficiency is maximised with
assembly.  If you were looking at a complex monster like a Pentium, with
it's dual pipelines, tendency to get bubbles, etc, don't you think a
compiller would be better at keeping it running at max?
OTOH, programmer efficiency will always land on the side of c - one line of
c = many lines asm to do same thing - and it takes same length of time to
code/debug per line. (assuming non buggy compiler, which is not always
valid)

MikeS
<RemoveMEmikesmith_ozTakeThisOuTspamspamrelaymail.net>

{Quote hidden}

1997\10\09@230430 by James M.

flavicon
face
Clyde, you are, without doubt, 110% correct!
You sir, deserve a lot of respect for the superb
software product you have created:  C compiler
for the PIC.  Could I interest you at looking at
ATMEL and Scenix?
James

----------
{Quote hidden}

its a
> > matter of exploring the darkest aspects of your hardware (by the way
>
> The point is that using such tricks in hand-coded assembler greatly
increases
> the chances that later on you will change something that breaks your
> clever optimization. A compiler on the other other hand rewrites the
> assember code each time it compiles the source, so it can check
> the validity of such clever tricks each time - you have to remember
> to do it.
>
> > By the way compilers are made by programmers, aren't they, so I think
> > all this discussion as no point at all, because the code a compiler
>
> Exactly my point; the limiting case of both hand-written and
automatically
> generated code is the same. It's just a matter of how much time you have
> to spend to get there, and how much time you have to spend later
> maintaining it. On a small project (say < 1K of code) it's not hard
> to make a case for using assembler. As the project gets larger it gets
> harder and harder to make that case. At some point the growing complexity
> of the project makes it impossible to write in assembler (the time
required
> to write code grows exponentially with the size of the project).
>
> It is true that a good compiler can routinely out-code an average
assembler
> programmer. The difference between an average programmer and a hot one is
> an order of magnitude or so. Of course no-one on this list is merely
average :-)
>
> Cheers.
>
> --
> Clyde Smith-Stubbs               |            HI-TECH Software
> Email: clydeSTOPspamspamspam_OUThtsoft.com          |          Phone            Fax
> WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
> PGP:   finger spamBeGoneclydeSTOPspamspamEraseMEhtsoft.com   | AUS: +61 7 3354 2411 +61 7 3354 2422
>
---------------------------------------------------------------------------
> ANSI C for the PIC! Now shipping! See http://www.htsoft.com for more info.

1997\10\10@004348 by Clyde Smith-Stubbs

flavicon
face
On Thu, Oct 09, 1997 at 08:02:45PM -0700, James M. wrote:
> Clyde, you are, without doubt, 110% correct!
> You sir, deserve a lot of respect for the superb
> software product you have created:  C compiler

Well, I'd just like to say that this list has been a valuable resource
in the process, there are a lot of clever people who make excellent
contributions.

> for the PIC.  Could I interest you at looking at
> ATMEL and Scenix?

The compiler will be enhanced to support the Scenix SX. I was very pleased
to actually see chips at the ESC, and the SX running at 100MHz certainly
was impressive. Currently we're waiting on the data sheet - it's supposed
to be on its way. Since the SX is a PIC enhancement, adding support for it
will not be hard.

WRT the Atmel AVR, this is also a chip we're interested in, but of course
it's going to be more work to support than the SX, since it's a totally
different architecture. The 1200 looks too low-level to really support
compiled code (I doubt I'd want to use it myself even in assembler) but
the 8515 and up should be fine.

The time schedule for this is uncertain, as there are other projects we're
talking to various people about right now, and there are only some many things
that we can do at the same time.

--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: KILLspamclydespamBeGonespamhtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger EraseMEclydespamEraseMEhtsoft.com   | AUS: +61 7 3354 2411 +61 7 3354 2422
---------------------------------------------------------------------------
ANSI C for the PIC! Now shipping! See http://www.htsoft.com for more info.

1997\10\14@082918 by mike

flavicon
picon face
In message  <@spam@19971010144159.55958@spam@spamspam_OUThtsoft.com> spamBeGonePICLISTspamKILLspamMITVMA.MIT.EDU writes:
> WRT the Atmel AVR, this is also a chip we're interested in, but of course
> it's going to be more work to support than the SX, since it's a totally
> different architecture. The 1200 looks too low-level to really support
> compiled code (I doubt I'd want to use it myself even in assembler) but
> the 8515 and up should be fine.
>

Clyde,

I was at a seminar a week or two ago at which the main speaker
(I don't have his name to hand) was one of the top software guys
in Norway for the AVR software.

He said at that meeting that they were working on their own C compiler
which would be available for nothing as their objective was to sell
silicon not software. If this is the case, it may well affect sales
of your own compiler.

There are other moves down this road: Altera have made their FPGA
design software available for download on the web. I don't know if
Microchip will go down that route with their C compiler, but if the
comments of some of the users on this list are anything to go by, it
may be the only way they will be able to shift it <g>.

Regards,

Mike Watson

1997\10\15@103448 by terogers

flavicon
face
Mike Watson wrote:

> Clyde,
>
> I was at a seminar a week or two ago at which the main speaker
> (I don't have his name to hand) was one of the top software guys
> in Norway for the AVR software.
>
> He said at that meeting that they were working on their own C compiler
> which would be available for nothing as their objective was to sell
> silicon not software. If this is the case, it may well affect sales
> of your own compiler...

Yeah, if history is any teacher, this will create an instant market for Clyde's
product, which will work properly and be supported by people who are generating
postive cash flow.

--Tom Rogers  VP-R&D  Time Tech Inc.

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