Searching \ for '[EE] Re: C or asm?' 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/language/index.htm?key=asm
Search entire site for: 'Re: C or asm?'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Re: C or asm?'
2006\02\19@093127 by Xiaofan Chen

face picon face
Added the [EE] tag.

On 2/19/06, David VanHorn <spam_OUTdvanhornTakeThisOuTspammicrobrix.com> wrote:
> >
> >
> > Doesn't seem like it should be a religious war, though, because the
> > answer you gave is so obviously correct that it is very difficult for me
> > to understand how anyone could argue with it.  Although perhaps that is
> > what a religious war is -- different people having different views, and
> > each one convinced that his view is obviously correct.  :-)
>
>
> :)  I'm surprised that the responses have been so sparse. Perhaps everyone's
> away from their keyboards.

Maybe the reason is that it does not have a tag.

> I do all my projects in assembler. I am learning C, but I am reluctant to
> use it in any real project, because I see that it adds a couple of layers of
> problems to the mix.  I don't have to worry about compiler bugs, or what the
> compiler will make out of my code.  I don't have to worry that changing one
> statement will cause some "ripple effect" and make changes elsewhere because
> the optimization now works out differently.
>
> Frankly, I'm surprised at the relatively primitive level of the compilers
> I've seen. Optimization seems pretty poorly done.

But there are many good compilers for PIC (Hi-Tech PICC), AVR (IAR and
AVR-GCC), MPS430 (IAR and MSP-GCC). AVR-GCC and MSP-GCC are free
open source compiler. SDCC for PIC may not be so good yet but SDCC for
8051 is said to be not so bad (okay not as good as Keil).

> Part of it I'm sure, is how I was brought up, but I think the exposure to
> the machine's internals is very important.  "Buy a bigger chip" isn't always
> an option, and sometimes you really need all the performance you can get,
> and a compiler isn't going to do your thinking for you here.. You have to
> know what's the fastest way to get something done on THIS machine.
> --

In general, I think asm is necessary for smaller MCUs like PIC. However it
is quite okay to do projects with pure C even for PICs. Inline assmebly or
assembly routines can be used for some critical routines (for example,
some C libraries are written in assmebly).

For hobbyists, I think it is even more possible to use a big MCU and then
use C for projects. But it is just one's choice to use C or asm.

Regards,
Xiaofan

2006\02\19@101507 by Wouter van Ooijen

face picon face
> In general, I think asm is necessary for smaller MCUs like
> PIC.

Why?

I often have a project where the PIC hardware costs are small, and a 1k
code 12F or 16F chip will do the trick when programmed in C, so why
shouldn't I use C?

Wouter van Ooijen

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


2006\02\19@104913 by Daniel Chia

flavicon
face
>
> In general, I think asm is necessary for smaller MCUs like PIC.
However it
> is quite okay to do projects with pure C even for PICs. Inline
assmebly or
> assembly routines can be used for some critical routines (for example,
> some C libraries are written in assmebly).
>
> For hobbyists, I think it is even more possible to use a big MCU and
then
> use C for projects. But it is just one's choice to use C or asm.
>
> Regards,
> Xiaofan
>

Honestly, I think even on a small MCU it's possible to use C. However
for the more time-critical portions it would be wise to revert back to
assembler when needed. Space wise, I would think that if you are really
going to start filling up that several k of flash using assembler would
prove to be a big headache anyway.

>> David VanHorn wrote:
>>
>> Part of it I'm sure, is how I was brought up, but I think the
exposure
>> to the machine's internals is very important.  "Buy a bigger chip"
>> isn't always an option, and sometimes you really need all the
>> performance you can get, and a compiler isn't going to do your
>> thinking for you here.. You have to know what's the fastest way to
get
>> something done on THIS machine.
>>

How does C not expose you to the machine's internals? If your referring
to the library functions, well there are libraries for assembler as
well. If you meant the MCU core, then its slightly true, however if you
really need the performance you'll know about the innards about the MCU
core anyway.

Perhaps speed might be the worrying point but your code probably spends
majority of its time in a few functions which you can pick and optimise
in assembler.

In any case nowadays the costs of getting a slightly bigger MCU is
minimal since the newer MCUs all have quite a bit of flash.



------------------------------------------------------------------------
Daniel Chia

"Genius is one percent inspiration and ninety-nine percent
perspiration."

    - Thomas Edison

E-mail: .....danielcjhKILLspamspam@spam@yahoo.com.sg
MSN: danstryder01spamKILLspamyahoo.com.sg
ICQ: 37878331
------------------------------------------------------------------------

Send instant messages to your online friends http://asia.messenger.yahoo.com

2006\02\19@121758 by Bob Axtell

face picon face
Wouter van Ooijen wrote:

{Quote hidden}

You are right, Wouter, and it makes perfect sense.

But my projects were always heavier. I would begin with C and eventually
run out of (1) Memory (2) code space (3) clock speed [[check 1/2/3 as
needed]].

I would then rewrite the entire project in assembler. So I now have 100s
of tested routines, all known to work, ready to drop in (with minor
tinkering)
to do 32-bit math, RS232, square root, etc. Just like C, without having
to fool with C.

To keep from having to pay for good C compilers, if I just HAVE to have a
high level language, I use your JAL, Wouter. Its free. and it works good.

--Bob

--
Note: To protect our network,
attachments must be sent to
.....attachKILLspamspam.....engineer.cotse.net .
1-520-850-1673 USA/Canada
http://beam.to/azengineer

2006\02\19@135209 by Wouter van Ooijen

face picon face

> But my projects were always heavier. I would begin with C and
> eventually run out of (1) Memory (2) code space (3) clock speed
> [[check 1/2/3 as needed]].

If my typical conditions hold (lov volume projects) I would simply take
my C code (or maybe Jal :) and hop to the next higher chip. If necessary
I can hop to an ARM, or maybe (never done that yet) a single-board PC.
But if you are working on high-volume projects the best way might be to
code it all in asm in the smallest possible chip.

Wouter van Ooijen

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


2006\02\20@083256 by peiserma

flavicon
face
piclist-bounces@mit.edu wrote:
>> In general, I think asm is necessary for smaller MCUs like PIC.
>
> Why?
>
> I often have a project where the PIC hardware costs are
> small, and a 1k code 12F or 16F chip will do the trick when
> programmed in C, so why shouldn't I use C?

ditto here. I did a project for an rfPIC entirely in C that did
quadrature decoding of two hall effect switches, some counting
and transmitted a packet of bytes with a 16-bit checksum (my
one-sentence summary of the project). Used about 1/2 of the
available space.

You need to know the internals of the mcu, of course. knowledge
of asm is a huge advantage, but not essential. For example, I
have trained a few co-op students (engineering students who
work 1/2 year, study 1/2 year), and they use C exclusively. They
all knew a little C. None of them knew any assembly.

I do tell them that in my opinion, knowledge of assembly is
mandatory if they intend to pursue anything related to micros.
Nothing gets you closer to the code or lets you understand what's
going on better (all IMHO) than assembly. Knowing assembly gives
you access to the huge amount of examples found on the piclist
and microchip.com....

I do know asm. I have programmed PICs, 8051's and the MC6800 in
assembly for years before the boss approved a compiler. But ever
since we got the compiler, I've used C on PICs exclusively.

However, I consider myself better at C than assembly. That is a
big reason for my preference. Whatever works best for the project
given the resources you have available, right?

2006\02\20@095301 by Wouter van Ooijen

face picon face
> You need to know the internals of the mcu, of course. knowledge
> of asm is a huge advantage,

Indeed. I am doing an ASM course right now, and one of the things I tell
the students is that they are not likely to use asm often, but it is
still good to know ASM (reading at least) so you can see (in the
compiler-generated listing) how you should (or should not) use C. (And
of course it is handy to be able to deetect when the compiler has a
bug.)

Wouter van Ooijen

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


2006\02\20@165823 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> You need to know the internals of the mcu, of course. knowledge
>> of asm is a huge advantage,
>
> Indeed. I am doing an ASM course right now, and one of the things I tell
> the students is that they are not likely to use asm often, but it is
> still good to know ASM (reading at least) so you can see (in the
> compiler-generated listing) how you should (or should not) use C. (And
> of course it is handy to be able to deetect when the compiler has a
> bug.)

I find that studying a compiler's list output is one of the more fun ways
to learn YAAWN (yet another assembler we need :).

You learn how the assembler works on a real-world application (albeit
simple at that point, probably, but more complex than if you would start
out with assembler) with real-world code that is supposed to do real-world
things in really big applications, too, and you learn how the compiler
works. You can look at non-optimized code and see clear structural elements
and how they are implemented in that assembler, you can turn on
optimization and see how things can be shuffled around to save space or
time.

Gerhard

2006\02\20@181822 by John Nall

picon face
Gerhard Fiedler wrote:
> Wouter van Ooijen wrote:
>  

And no particular need to quote what those two gentlemen wrote, because
you know what it is.  :-)    But this is kind of an interesting thread,
in that it brings back memories of when I first looked at the C compiler
for writing pic code and recoiled in horror:  "My God, that is not ANSI
C!!!"   Which led to a fairly long discussion . . . and my memory is
that I came out second best, after being completely out-argued by some
of the more experienced Old Timers. But I took it in good humor,
figuring that I might learn something (which I did).  :-)

And so it makes me wonder.  What would be the design of a new HLL for
programming pic's?  Clearly (to me it is clear, anyway) it would like a
heck of a lot like C, but  there would be a few subtle (well, maybe not
so subtle) differences.  What we would want, I think, is the ability to
do while loops, and for loops, and complex (in the sense of convoluted
-- not imaginary) arithmetic expressions, while still retaining a very
intricate capability to fiddle with bits.  You might say: "Oh, yes, C
lets you fiddle with bits."  Well, sort of, yes.  I would like for it to
go deeper.

This is all just musing . . . what would a language, somewhat like C but
written specifically for pic's, look like???


2006\02\20@192459 by Gerhard Fiedler

picon face
John Nall wrote:

> And so it makes me wonder.  What would be the design of a new HLL for
> programming pic's?  Clearly (to me it is clear, anyway) it would like a
> heck of a lot like C, but  there would be a few subtle (well, maybe not
> so subtle) differences.  What we would want, I think, is the ability to
> do while loops, and for loops, and complex (in the sense of convoluted
> -- not imaginary) arithmetic expressions, while still retaining a very
> intricate capability to fiddle with bits.  You might say: "Oh, yes, C
> lets you fiddle with bits."  Well, sort of, yes.  I would like for it to
> go deeper.

One thing I miss sometimes are bit pointers. Some (many? most?) compilers
have (non-standard) bit types that allow bit handling similar to other
variables. But so far I haven't seen a bit pointer type.

What have you thought of when you wrote "go deeper"? There is only so much
you can do with bits :)


> This is all just musing . . . what would a language, somewhat like C but
> written specifically for pic's, look like???

This is a trick question, isn't it? :)  IMO the question about /the/
language is bound to fail to get an answer. The reason is that there are so
many programming styles. For example some Basic implementations can have
pretty cool features, in being able to run as p-code interpreted or
completely compiled code, or even interpret pure ASCII command lines. I
also always wondered how a real-time system in Forth would look like. I
find the concept of the language extremely intriguing, but there might be a
catch, because it didn't catch on much. (Probably better suited for a
stack-oriented architecture though, so slightly off-topic here.) C is more
a HLA (high level assembler) for the traditionalists and for whoever knows
it from somewhere else. Pascal is something for the purists who would use C
but find C too dirty. Then there are dozens of languages most people have
never heard of...

So in the end you do what all the compiler writers do: you pick your base
language (or language concepts), leave out what you don't want and add what
you need. What base language you use is an /extremely/ personal choice :)

I personally have a good relationship with C, but that's mostly because I
know it well and I have a compiler that works well. I'm pretty sure there
are other compilers for other languages out there I could be happy with --
but I find it difficult to come up with some kind of feature set
specification. Of course you need the basics, but every decent system has
that. The real goodies though depend a lot on the structure of the
language, and will often be quite different.

For example you can find that the p-code thingy of some Basic dialects is a
cool thing because all of a sudden you can put a (slow) megabyte program in
your smallish PIC, just by adding an external serial Flash memory. But I'm
not sure whether that feature could be easily or at all integrated with a
language like C (or maybe JAL). There probably are a few architectural
characteristics that need to be given so that this is possible.

Gerhard

2006\02\20@202454 by John Nall

picon face
Gerhard Fiedler wrote:
> > What have you thought of when you wrote "go deeper"? There is only so much
> you can do with bits :)
>  
.
A good question, and I don't know exactly how to answer it, because I
have just been kind of thinking about this and wondering about it,
without really coming up with any concrete ideas.  It is true, of
course, that "there is only so much that you can do with bits," but a
bit is a variable, even though it can only have two values -- on or
off.  0 or 1.  But once you get into variables, then you get into the
question of indirect addressing (some people prefer to say "pointers,"
but I think that indirect addressing is a better term).  Now, obviously,
an address can point to another address.  But can a bit point to another
bit?  Would we want it to?  And, if so, why?
>
>  
>> This is all just musing . . . what would a language, somewhat like C but
>> written specifically for pic's, look like???
>>    
>
> This is a trick question, isn't it? :)
.Trolling, you mean?  No.  There are some very clever minds out there,
and asking for some original thinking is not the same as raising a
controversial subject just to get people screaming about it.  Are we
really willing to say that C is the ultimate language for pic
programming?  Really?  Really and truly?  Not a chance in hell of
imagining anything better?
.




2006\02\21@030933 by Wouter van Ooijen

face picon face
> Now, obviously,
> an address can point to another address.  But can a bit point
> to another bit?

only on a 00F001

Wouter van Ooijen

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


2006\02\21@030934 by Wouter van Ooijen

face picon face
> This is all just musing . . . what would a language, somewhat
> like C but written specifically for pic's, look like???

Jal version 14.8

note: version 1.0 will be there real soon now (tm)

Wouter van Ooijen

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


2006\02\21@043139 by Alan B. Pearce

face picon face
>And so it makes me wonder.  
>What would be the design of a new HLL for
>programming pic's?

Isn't it called JAL ????

2006\02\21@070601 by Gerhard Fiedler

picon face
John Nall wrote:

>> What have you thought of when you wrote "go deeper"? There is only so
>> much you can do with bits :)
>
> [...] but a bit is a variable, even though it can only have two values
> -- on or off.  0 or 1.  

Exactly :)  And many compilers treat it that way. You can do logic
operations and math with it.

> But once you get into variables, then you get into the question of
> indirect addressing (some people prefer to say "pointers," but I think
> that indirect addressing is a better term).  

I don't think it has much to do with preference, it has more to do with
what you are talking about. The two terms are not from the same "domain",
so to speak. "Indirect addressing" is a concept, talks about how to
interpret the argument of a (usually assembler) command. "Pointer" is a
variable type, mostly in C-type languages. The C-equivalent of the
assembler concept of "indirect addressing" would probably be "dereferencing
a pointer", but it's still not quite the same.

> Now, obviously, an address can point to another address.  But can a bit
> point to another bit?  Would we want it to?  And, if so, why?

Right... orthogonality -- I liked especially the "if so, why" part :)


>> This is a trick question, isn't it? :)
>
> Trolling, you mean?  No.  

No, I didn't mean "trolling". But it's a question about individual
preferences.


> Are we really willing to say that C is the ultimate language for pic
> programming?  Really?  Really and truly?  

No, of course not, I don't think many people are saying that, not "really"
and not "truly" and not plainly :).

If you read the remainder of the paragraph that started with the "trick
question" comment, there are many other languages out there, some similar
to C, some not. One "C advantage" is that it is, so to speak, a "high level
assembler" -- you stay pretty close to the hardware and the assembler, yet
are on a level that allows to program reasonably independently of the
actual architecture. Another is that it is relatively well standardized,
which means that switching from one micro family to another is easier than
with most other languages. This is a consideration that may or not be
important to a hobbyist, but it is for many who program professionally. It
is an argument for C that's not really linked to any of it's other
characteristics in particular (it's a bit linked to it being rather low
level, I think), it's just that it /is/ standardized and available for
pretty much every micro family.

C is here by the power of the status quo, so to speak. But there's nothing
especially "ultimate" about C. And the "ultimate" language for PICs, if
there were one, won't catch on widely if it isn't at least a bit "ultimate"
for every other processor family out there, too.

Basic, for example, for how "basic" it may be :), is usually on a higher
level. That's also one of the reasons why Basic often is easier to get
started with than C (or assembler) -- with a few lines of nice and clean
and easy to read code you interface to the serial port and turn an LED on
and off with commands sent from the PC. This may be one of the reasons to
choose it over e.g. C. OTOH, you won't find easily a Basic dialect that you
can use on a PIC, on an 8051, on an AVR, on an ARM and on your PC -- they
are usually quite proprietary, and limited to whatever the compiler vendor
supports.

I'm not sure I can come up with a complete list of languages for the PIC,
but I can start one here:

Basic, C, C++, Forth, Jal, Java, Logo (? I think I've seen one once),
Pascal. Anything I missed? Most of them have production-quality
implementations.

Anybody here who uses Forth and would like to tell me about it?

Gerhard

2006\02\21@094319 by John Nall

picon face
Wouter van Ooijen wrote:
>> This is all just musing . . . what would a language, somewhat
>> like C but written specifically for pic's, look like???
>>    
>
> Jal version 14.8
>  
.
Really?  I hadn't realized that about Jal.  I had always assumed that it
was just another variation of Basic.  Guess I had best stop making inane
comments and study up on it.  Which I will do, PDQ.

2006\02\21@101957 by Wouter van Ooijen

face picon face
>> Jal version 14.8
>
> Really?  I hadn't realized that about Jal.  I had always
> assumed that it
> was just another variation of Basic.  Guess I had best stop
> making inane
> comments and study up on it.  Which I will do, PDQ.

Note that I was only partially serious. Jal was written especially for
(PIC) microntrollers, but as yet (1.00 and below) it is a very limited
language (for instance: only bytes and bits, no arrays, pointers,
records, etc). But it does have some things that are IMHO right for a
PIC language, like: no recursion (so the stack depth can be determined
by the compiler, and variables can be allocated static-stack wise), the
bit is a real data type (in C it is not), and (more a compilert than a
language issue) constant expressions are calculated at compile time, and
dead code is removed (including never-called procedures).

Cuurently Jal 1.00 is being developed/debugged (not by me though) which
addresses some of the above limitations.

Wouter van Ooijen

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


2006\02\21@103847 by John Nall

picon face
Wouter van Ooijen wrote:
> > Note that I was only partially serious.
.
So then, Wouter, you were just taking advantage of my youth and
inexperience and putting me on, huh?  For shame! :-)
.

> > Cuurently Jal 1.00 is being developed/debugged (not by me though) which
> addresses some of the above limitations.
>  
.
Yeah, I took a quick glance at the SourceForge page, and see that it is
still being developed.  Probably an interesting project to work on.  I
really like the idea of a bit data type.  But arrays and pointers are a
must, IMHO.  Oh well.  Back to C, which I suppose is another one of
those many things that "aren't perfect but better than anything else
presently available."

2006\02\21@112232 by Timothy Weber

face picon face
John Nall wrote:
>>> Cuurently Jal 1.00 is being developed/debugged (not by me though) which
>> addresses some of the above limitations.
>>  
> .
> Yeah, I took a quick glance at the SourceForge page, and see that it is
> still being developed.  Probably an interesting project to work on.  I
> really like the idea of a bit data type.  But arrays and pointers are a
> must, IMHO.  Oh well.  Back to C, which I suppose is another one of
> those many things that "aren't perfect but better than anything else
> presently available."

Just checking - Do you know about BoostC?  It has a bit data type.
--
Timothy J. Weber
http://timothyweber.org

2006\02\21@114523 by John Nall

picon face
Timothy Weber wrote:
>
> > Just checking - Do you know about BoostC?  It has a bit data type.
>  
.
Interesting.  I didn't know that it had a bit data type, no.  But BoostC
has two problems, from my perspective.  It costs, and I try to use
software that is free whenever possible.  Not because I'm a cheapskate,
but because my wife only lets me put a certain amount of money into such
things, and I would rather buy test equipment than software.  More
importantly, it does not support the 30F chips, which is where I am
currently trying to concentrate my efforts.  My current project is to
move from using assembler on the 30F to using C30, and it was reading
the C30 manual that prompted the original comment.

2006\02\21@114857 by Wouter van Ooijen

face picon face
> Just checking - Do you know about BoostC?  It has a bit data type.

I think that is the Baranov/Kanda compiler? Yes I know about it - at one
time Pavel and I worked just 100m apart!

But maybe you can check this bit data type: can you take the address of
a bit and do arithmetic with that address and pass it around, just like
other addresses? And can you pass a bit as parameter to a function? If
all this is true (and the generated code does not hold any unpleasant
surprises) it is a good implementation of a bit data type.

But that does not negate the argument that C (in the sense of ANSI C or
k&R C) does not have a bit data type.

Wouter van Ooijen

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


2006\02\21@123505 by Timothy Weber

face picon face
John Nall wrote:
> Interesting.  I didn't know that it had a bit data type, no.  But BoostC
> has two problems, from my perspective.  It costs, and I try to use
> software that is free whenever possible.  

> More importantly, it does not support the 30F chips,

That sounds like it would be a deal breaker.  But if you find yourself
using 16F or 18F chips, a Lite license that supports 2 code banks is
$5... not technically free but I'd call it negligible.
--
Timothy J. Weber
http://timothyweber.org

2006\02\21@124401 by Timothy Weber

face picon face
Wouter van Ooijen wrote:
> I think that is the Baranov/Kanda compiler? Yes I know about it - at one
> time Pavel and I worked just 100m apart!

That's a lot of PIC experience per square meter!

> But maybe you can check this bit data type: can you take the address of
> a bit and do arithmetic with that address and pass it around, just like
> other addresses? And can you pass a bit as parameter to a function? If
> all this is true (and the generated code does not hold any unpleasant
> surprises) it is a good implementation of a bit data type.

No, it's not that robust.  I don't have the docs in front of me, but
it's basically just a convenient way to store flags and have the
compiler manage combining them into bytes for storage.

> But that does not negate the argument that C (in the sense of ANSI C or
> k&R C) does not have a bit data type.

True.  I would agree that ANSI C is not, by itself, very suitable for
PICs - without essential, non-portable extensions.
--
Timothy J. Weber
http://timothyweber.org

2006\02\21@124406 by Alan B. Pearce

face picon face
>More importantly, it does not support the 30F chips,
>which is where I am currently trying to concentrate
>my efforts.  My current project is to move from using
>assembler on the 30F to using C30, and it was reading
>the C30 manual that prompted the original comment.

So have you looked at the Student Edition of Microchips C30 compiler? I
would have thought they would have a data type in there to allow bits of
ports to be manipulated.

2006\02\21@130155 by Stef Mientki

flavicon
face

>  
>
>>>Cuurently Jal 1.00 is being developed/debugged (not by me though) which
>>>      
>>>
>>addresses some of the above limitations.
>>  
>>    
>>
>.
>Yeah, I took a quick glance at the SourceForge page, and see that it is
>still being developed.
>
Well the real development and testing is currently done outside SourceForge,
and indeed the new version whatever the number will be,
will support bit, byte, word, dword, signed /unsigned, arrays, etc.

Stef Mientki, just a betatester

2006\02\21@135344 by John Nall

picon face
Alan B. Pearce wrote:
> > So have you looked at the Student Edition of Microchips C30 compiler? I
> would have thought they would have a data type in there to allow bits of
> ports to be manipulated.
>  
.
Oh yes.  I have the student edition of C30.  That is what I am currently
learning to use.  So far as I know up to this point, they have the
standard C data types (int, char, etc.) but not a specific data type for
bits.  The standard bit manipulation operators that are defined in ANSI
C are there (so far as I know -- I am just starting with it) and
obviously bits of ports can be manipulated with those.  They also use a
"structure" for bit operations.  For example:  " T!CONbits.TON = 1; ".  
I'm not complaining about C30 -- I'm grateful to Microchip to making it
available to us.  Wish it produced more optimized code, though.  I
understand, of course, that they removed the optimizer for the student
edition, and have no quarrel with  that.  But it kind of hurts to look
at  the assembly language that  the student edition produces and see how
ugly it looks! :-)   Not  that it is that hard to go in and optimize the
results by hand, though.  They seem to just compile each line of C code
as a separate operation, so that there is not any particular attempt to
utilize the registers to hold variables and/or constants that are going
to be used over and over.

2006\02\21@135832 by Wouter van Ooijen

face picon face
> So have you looked at the Student Edition of Microchips C30
> compiler? I
> would have thought they would have a data type in there to
> allow bits of
> ports to be manipulated.

To manipulate, yes, C can do that easily. But that does not make a bit a
datatype.

Wouter van Ooijen

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


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