Searching \ for '[EE]: C, assembly, other languages' 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=language
Search entire site for: 'C, assembly, other languages'.

Exact match. Not showing close matches.
PICList Thread
'[EE]: C, assembly, other languages'
2007\03\11@064509 by wouter van ooijen

face picon face
(switched to EE because this is not realy about PICs, and to shake off
some of the heat)

@James: I agree that this discussion can get people to behave
religious-like, but this discussion is far from religious. The
interesting part of the discussion can be decided on measurable
parameters (time, money, product quality, etc). The other (emotional)
part should be avoided because it is indeed religious (= non-decideable,
and likely to evoke overly strong sentiments).

I use both assembly and a set of higher languages (I even wrote one),
both for fun (hobby) and for profit. I also teach assembley (PIC and
ARM), C and C++ to students. In my former career I used lots of
different languages, mainly in industry and space. So I think I can
claim some authority.

> Afaik, the rule of thumb is to use the highest level programming
> language available for the task.

That's what I preach to my students. Java, C# or Python (or Tcl, Awk,
Perl, etc) on a PC if you can get away with the slower speed, C++ if you
need the speed (or one of its more fancy features). Asm on a PC is rare
(maybe in the critical part of a graphics engine). On a PIC: Basic, C,
Pascal, Jal, etc if possible, asm only if necesarry (and believe me, it
seldom is). And if you need *some* asm limit it to that: mixing is not
that difficult.

Note that "highest" can only be defined relative to the taks at hand.
Most taks are very alike in this respect, but there are (rare) tasks for
which assembly might be higher than any other language. There are also
tasks where a non-mainstream language like Lisp, SETL or Haskell is much
"higher" than anything else.

There can of course be overriding arguments for another choice:
available libraries and frameworks, tool quality, personal preferences,
tool cost, effort invested in libraries and personel, etc. But even then
it might be worth to do a back-of-the-evelop cost calculation, even if
cost is to be expressed in hours instead of cash.

People with a lot of experience in a particular field often develop a
tunnel vision: they know what is best for their field, completely
forgetting that there are other fields that are very differnt from
theirs. Keep this in mind when someone (you yourself?) writes something
like "I never needed ..." (referring to a C feature, or something that
can be done only in asm).

Note that I mostly say that assembley *programming* can and should be
avoided. Especially on uControllers assembley *knowledge* (at least
passive, == reading) can be very usefull even when programming in a
higher language.

I teach both Electronics and Informatics students. I noticed a slight
differece between the two groups: even at the start of their education
the Electronics guys are relatively more at easy with assembly compared
to the Informatics gues, who are more at home with C or higher. Maybe
the brains of the two groups are wired differently.

> Simple example: Write code that clears bit 6 of variable i. Not so
> easy in standard C. Something like:  i &= ~(1<<6); Whereas PIC
> assembly has the more straightforward: bcf   i,6

For *you* the asm might be easier to read, but for one who is fresh to
both I am not so sure. And the C version works equaly well an AVR, ARM,
etc (so a C programmer coming from another CPU will instantly recoginse
the C line!). And in the C version the 6 can be a variable, in the asm
version it can't. And the asm version assumes that i is in the current
bank. (two more fitfalls to learn to a fresh asm programmer).

Wouter van Ooijen

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

2007\03\11@083856 by Gerhard Fiedler

picon face
wouter van ooijen wrote:

Quite good summary, IMO. I agree with all of it.

> There can of course be overriding arguments for another choice:
> available libraries

Most companies and professionals accumulate quite a code base after years
of work. This available code base, whether libraries or not, can give the
previous choice of language a huge advantage over anything else.

It can go so far as Olin's development environment. He says he programs in
assembler, and technically that's correct. But in reality, he uses his
ASPIC development environment and libraries extensively, and I'm sure that
without a thorough understanding of both you wouldn't understand much of
his code that's built on it. So it's not really plain assembly that he
uses, it is in that area where the distinction between language and
application framework become somewhat blurry. (Not in theory -- it's easy
to say which is which --, but in practice: in the end, they have both the
same effect and objective.)

When programming bigger systems, the application framework question becomes
much more important than the language question. It takes an experienced
programmer usually not that much time to get up to speed in a different
language, as it usually will be similar to something she already knows. But
getting up to speed in a complex application framework can take much
longer.

Gerhard

2007\03\11@091230 by wouter van ooijen

face picon face
> When programming bigger systems, the application framework question
becomes much more important than the language question.

Agreed. C++ and Ada95 are very complex languages compared to a more
simple Java, C or Pascal. But even such complex languages are peanuts
compared to a serious application framework. Programmers that realy
understand such frameworks generaly don't consider learning a new
language a big effort.

This used to be a non-issue on smaller microcontrollers, but with the
shift of what we consider small and the arrival of integrated USB and
integrated or easily interfaceable Ethernet, CAN etc. this has become an
issue for small uC's too. Did any of you develop his own USB code for
18F's? Or his own TCP/IP stack for the ENC28? Some might, but I think
the majority will use the uChip-provided code. It helps of course that
there is a more-or-less free C18 compiler and the uC code is for that
compiler. But there will always be a class of uC where application
frameworks make little sense (think 10F's).

Wouter van Ooijen

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



2007\03\11@184209 by William Chops Westfield

face picon face

On Mar 11, 2007, at 3:45 AM, wouter van ooijen wrote:

>> Afaik, the rule of thumb is to use the highest level programming
>> language available for the task.
>
> That's what I preach to my students.

There's an exception some place, I think, in specialized "high level
languages" produced by a vendor for a particular processor that lack
any portability.  Things like cypress's PSoC Designer just make me
nervous.  Likewise, Smalltalk has never caught on (maybe it's that
"for the task" part; Smalltalk always struck me as the sort of ultimate
HLL as designed by HLL designers without any particular task in mind,
and thus is never seemed well suited to ANY particular task.)

And I guess that someplace one gets to argue what makes one HLL
"higher" than another.  I've never been much enamored of OOLs like
C++ or Java, and from what I've seen a lot of their advantages stem
more from extensive libraries (ok, "classes") (standard and otherwise)
than "lower level" languages (admittedly, there are features of the
languages that make creating extensive libraries using complex data
structures easier to publish and import than in lower level lanaguages.)

BillW

2007\03\11@211045 by Tobias Gogolin

picon face
I also agree the best HLL is obviously not developed yet at least the
computer doesn't understand our HiQ that we may talk or think to it...

I think its a good idea to continue this thread outside of any specific
Microprocessor because the ultimate processor and OS and language of the
future are the ones that will make reconfigurable computing in programmable
logic arrays possible!
Ultimately in the real world many objects exist in parallel and communicate
with each other...
So kudos to the people that are developing things like http://www.jhdl.org !



On 3/11/07, William Chops Westfield <spam_OUTwestfwTakeThisOuTspammac.com> wrote:
{Quote hidden}

> -

2007\03\12@143151 by Vitaliy

flavicon
face
>> Simple example: Write code that clears bit 6 of variable i. Not so
>> easy in standard C. Something like:  i &= ~(1<<6); Whereas PIC
>> assembly has the more straightforward: bcf   i,6

Hm.. why not

i &= 0b11011111;

Also, there are C macros for things like rlcf.

Vitaliy


2007\03\12@153500 by Byron A Jeff

face picon face
On Mon, Mar 12, 2007 at 11:30:09AM -0700, Vitaliy wrote:
> >> Simple example: Write code that clears bit 6 of variable i. Not so
> >> easy in standard C. Something like:  i &= ~(1<<6); Whereas PIC
> >> assembly has the more straightforward: bcf   i,6
>
> Hm.. why not
>
> i &= 0b11011111;

>
> Also, there are C macros for things like rlcf.

0b isn't C standard syntax is it?

Yet another extension that isn't a part of the standard language.

The point is that even if you know base C, you'll have to learn a new
set of quirks to program in it.

BAJ

2007\03\12@155505 by Bob Blick

face picon face

--- Vitaliy <.....spamKILLspamspam@spam@maksimov.org> wrote:

> >> Simple example: Write code that clears bit 6 of
> variable i. Not so
> >> easy in standard C. Something like:  i &=
> ~(1<<6); Whereas PIC
> >> assembly has the more straightforward: bcf   i,6
>
> Hm.. why not
>
> i &= 0b11011111;

That'd be OK if you wanted to clear bit 5 :)

Cheerful regards,

Bob

2007\03\12@161509 by David VanHorn

picon face
>
>
> > Hm.. why not
> >
> > i &= 0b11011111;
>
> That'd be OK if you wanted to clear bit 5 :)


Isn't C supposed to prevent mistakes like that ?
(ducks and runs!)

2007\03\12@175015 by Rikard Bosnjakovic

picon face
On 3/12/07, Vitaliy <spamspamKILLspammaksimov.org> wrote:

> Hm.. why not
> i &= 0b11011111;

Because that's not standard C and most compilers won't compile it.

--
- Rikard.

2007\03\12@185714 by Vitaliy

flavicon
face
From: "Byron A Jeff wrote:
>> Hm.. why not
>>
>> i &= 0b11011111;
>
>>
>> Also, there are C macros for things like rlcf.
>
> 0b isn't C standard syntax is it?
>
> Yet another extension that isn't a part of the standard language.
>
> The point is that even if you know base C, you'll have to learn a new
> set of quirks to program in it.

IMO, to a C programmer, that would still be easier than learning assembly.
And you could also say:

i &= 0xBF    // 0xBF = 0b1011 1111

instead of the convoluted (and slower)

i &= ~(1<<6)

The only reason I made the first post, is because the comparison was made
unfairly.

Best regards,

Vitaliy

2007\03\12@185714 by Vitaliy

flavicon
face
Bob Blick & David VanHorn wrote:
>> > Hm.. why not
>> >
>> > i &= 0b11011111;
>>
>> That'd be OK if you wanted to clear bit 5 :)
>
>
> Isn't C supposed to prevent mistakes like that ?
> (ducks and runs!)

:) OK, you got me. But the same mistake could have been made in assembly.

Best regards,

Vitaliy

2007\03\12@190234 by Mike Harrison

flavicon
face
On Mon, 12 Mar 2007 22:50:12 +0100, you wrote:

>On 3/12/07, Vitaliy <.....spamKILLspamspam.....maksimov.org> wrote:
>
>> Hm.. why not
>> i &= 0b11011111;
>
>Because that's not standard C and most compilers won't compile it.

Compilers from suppliers keen to support useful features for embedded users do ( e.g. Hitech).
Ones from companies that think strict  adherence to standards is more important than adding
genuinely useful enhancements (e.g. IAR) don't.

This really is one of those enhancements that there is no excuse for embedded C compilers not to
support, as (a) it is very easy for them to code and (b) on the rare occasions that code needs to be
ported to a compiler that doesn't support it, replacement can be done easily with little risk of
errors in the conversion process.





2007\03\12@190520 by peter green

flavicon
face
> instead of the convoluted (and slower)
>
> i &= ~(1<<6)
If its slower (at runtime) than your compiler sucks! constant expressions shuold be completely evaluated at compile time.



2007\03\12@190730 by dpharris

picon face
Quoting Vitaliy <EraseMEspamspam_OUTspamTakeThisOuTmaksimov.org>:

....
> instead of the convoluted (and slower)
>
> i &= ~(1<<6)
>
Actually, I think most compilers would convert this to 'i &= 0b11011111', as it
is a compile time constant.  

David


2007\03\12@190801 by Marcel Birthelmer

picon face
> instead of the convoluted (and slower)
>

I don't think it would be slower, since constant calculations are
simplified at compile time.
- Marcel

2007\03\12@191029 by Alex Harford

face picon face
On 3/12/07, Vitaliy <spamspamspam_OUTmaksimov.org> wrote:
>
> IMO, to a C programmer, that would still be easier than learning assembly.
> And you could also say:
>
> i &= 0xBF    // 0xBF = 0b1011 1111
>
> instead of the convoluted (and slower)
>
> i &= ~(1<<6)

Why would that be slower?  That math should get done at compile time.

Alex

2007\03\12@191337 by David VanHorn

picon face
On 3/12/07, peter green <@spam@plugwashKILLspamspamp10link.net> wrote:
>
> > instead of the convoluted (and slower)
> >
> > i &= ~(1<<6)
> If its slower (at runtime) than your compiler sucks! constant expressions
> shuold be completely evaluated at compile time.


I was wondering about that..
Somebody please tell me there isn't a compiler out there that would do that
as six shifts???

2007\03\12@214109 by Vitaliy

flavicon
face
David VanHorn wrote:
>> > instead of the convoluted (and slower)
>> >
>> > i &= ~(1<<6)
>> If its slower (at runtime) than your compiler sucks! constant expressions
>> shuold be completely evaluated at compile time.
>
>
> I was wondering about that..
> Somebody please tell me there isn't a compiler out there that would do
> that
> as six shifts???

Jeez... don't you guys have anything better to do, besides counting my bits
and discovering errors in my logic? ;-D

Vitaliy

PS Peter -- it's "it's", not "its", and "then", not "than". ;)

2007\03\13@021247 by William Chops Westfield

face picon face

On Mar 12, 2007, at 1:15 PM, David VanHorn wrote:

>>> i &= 0b11011111;
>>
>> That'd be OK if you wanted to clear bit 5 :)
>>
Yes.  What you'd really use is a macro.  Maybe something like:

#define bcf(var, bit) var &= ~(1<<(bit))

And then in your C program you can say obvious stuff like:
       bcf(var, 5);
Then you'd sit there and hope that the compiler writers included
some special case optimization to reduce that back to the single
instruction it should be, since that's probably NOT a case that
generic C optimizers would catch.

 :-;
BillW

2007\03\13@022352 by William Chops Westfield

face picon face

On Mar 12, 2007, at 3:55 PM, Vitaliy wrote:

> instead of the convoluted (and slower)
>
> i &= ~(1<<6)
>
If that's slower than i=0xBF, then you need a new C compiler.
Math on constants can and should be done at compile time.

BillW

2007\03\13@031618 by William Chops Westfield

face picon face
On Mar 12, 2007, at 5:39 AM, Peter P. wrote:

> After all, compiler output *IS* machine code written using code
> generators made and optimized by expert assembly programmers.

Um.  Maybe.  Too often compilers are written by compiler experts who
AREN'T experts in the assembly language of the target processor.  My
university compiler class included only a tiny bit about code
generation,
and most of that was aimed at a "theoretical" machine.  (I wasn't very
impressed, being an assembly programmer at the time.)  Likewise,
witness how poorly the gcc "intermediate code" matches the architecture
of many common microcontrollers, for instance.  And We're not talking
about the modern set of micros designed with compiler optimization of
branch delay slots and cache handling in mind; we're talking about
quirky microcontrollers with instruction sets from the dark ages.


>> No compiler will ever be as code-space and/or speed efficient
>>  as a good assembler programmer
>
> I think that this is a myth.
>
Nah, it's just not a complete statement.  A good assembly programmer
can match even the best compiler, but a good assembly programmer would
be a fool to apply that level of effort to an entire large-ish program,
while the compiler can do so effortlessly.  OTOH, a compiler is likely
to throw away all its supposed space gains by including some massive
library that it needs a tiny piece from.  There are things that are
easy for an assembly language programmer to do, common in embedded
microcontrollers, that are very difficult for a compiler to match
simply because of requirements of the language.  Mixed size math (add
8 bits to a 16bit quantity.  A C compiler could do this, but it's NOT
the way that C is defined to work.)  Explicit use of the carry bit.
Compilers tend to be designed to support and optimize certain classes
of program, and alas embedded applications are seldom among them.
(that's for "generic" compiler technology.  And "computer science"
as applied to compilers.  And education.  It's certainly possible
that any given vendor has managed to figure out how to optimize
embedded applications on "typical" microcontrollers and does a very
good job.  But I've seem enough compilers do enough stupid things on
enough targets that I don't trust this supposed "super optimization"
will happen very often.

On the third hand, it's certainly also true that many applications
use so little memory even compilers of questionable merit will
do just fine.  Smaller and faster isn't necessarily better once your
program is already small enough and fast enough.  And it's a famous
failing of both C and assembly language programmers that they spend
too much time trying to optimize code where it really doesn't matter.

BillW

2007\03\13@041155 by wouter van ooijen

face picon face
> And it's a famous failing of both C and assembly language programmers
that
> they spend too much time trying to optimize code where it really
doesn't matter.

Not just assembly and C programmers :)

So, again: facing a choice between asm, C or some other language (same
holds for uC, tools, etc) one should a least attempt to quantify. The
figures might be only rough estimates, but even a rough estimate will do
when the figures for the alternatives differ widely. The only real
mistake is not to quantify, and base the decision on a gut feeling (that
was not previously calibrated by a set of calculations).

Wouter van Ooijen

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



2007\03\13@051833 by Peter P.

picon face
William "Chops" Westfield <westfw <at> mac.com> writes:

> On Mar 12, 2007, at 5:39 AM, Peter P. wrote:
>
> > After all, compiler output *IS* machine code written using code
> > generators made and optimized by expert assembly programmers.
>
> Um.  Maybe.  Too often compilers are written by compiler experts who
> AREN'T experts in the assembly language of the target processor.  My
> university compiler class included only a tiny bit about code
> generation,
> and most of that was aimed at a "theoretical" machine.  (I wasn't very
> impressed, being an assembly programmer at the time.)

The 'Dragon' book ('Compilers' - Aho, Sethi, Ullmann), which is supposedly about
compiler writing (and a standard university text for that) is so abstract that
one needs 2-3 additional books to be able to complete a simple compiler based on
it. The 'Interpretation of Computer Languages' (Abelman etc - the LISP book) has
a similar problem, excepting for the fact that LISP is interpreted so there is a
little bit of code to work with. University does not teach practical things
(notice that I do not have a degree ...). Not so long ago universities were
extremely proud of that, too. And I don't think that they got over it
completely. Not that they intend to (except for show, to please the <academic's
sneer>carreer needs</academic's sneer> of students - I am joking of course. I
never saw such an attitude. But I am a terrible liar.).

> Likewise,
> witness how poorly the gcc "intermediate code" matches the architecture
> of many common microcontrollers, for instance.  And We're not talking
> about the modern set of micros designed with compiler optimization of
> branch delay slots and cache handling in mind; we're talking about
> quirky microcontrollers with instruction sets from the dark ages.

gcc and sdcc are free compilers whose most important merits are that they exist,
and that they seem to support large projects using them. That's a lot for free
tools. They also set the entry level requirements for commercial tools imho.
Charging any money for anything that does less than those two is cheeky imho,
and whenever I compare features on some commercial tools I use this benchmark
too. There are also other compilers that set the level, like that CP/M C
compiler that was released free recently.

> >> No compiler will ever be as code-space and/or speed efficient
> >>  as a good assembler programmer
> >
> > I think that this is a myth.
> >
> Nah, it's just not a complete statement.  A good assembly programmer
> can match even the best compiler, but a good assembly programmer would
> be a fool to apply that level of effort to an entire large-ish program,
> while the compiler can do so effortlessly.  OTOH, a compiler is likely

Yes, exactly. And for this, it is best if the assembly programmer writes
everything in C and only puts in a function or two in optimized inline or
standalone assembly where it matters, and spends the time well polishing that.
Several successfull products are written like that, including high speed device
drivers, the Linux kernel and others like this. And I try to do it like that
when some piece of C is too slow or too large.

> to throw away all its supposed space gains by including some massive
> library that it needs a tiny piece from.  There are things that are

Yes but that is not so true for embedded. Most embedded projects use 'leaned' C
libraries which contain extra small functions precisely for this reason. Also
oftentimes embedded libraries are partially rewritten for the same reason. E.g.
leaned printf() and scanf() (if used at all) are very very common, and so are
some math function implementations which do not consume huge amounts of space
and time.

> easy for an assembly language programmer to do, common in embedded
> microcontrollers, that are very difficult for a compiler to match
> simply because of requirements of the language.  Mixed size math (add
> 8 bits to a 16bit quantity.  A C compiler could do this, but it's NOT

I don't think that that is a good example. Things like mixed size math usually
don't occur in programs written top down, and putting in an explicit cast at
the right place in the source should cause the compiler to issue a single,
efficient, sign-extending shift at the right place.

> the way that C is defined to work.)  Explicit use of the carry bit.

I think that there are ways to write code such that the gains of
'carry-bit-using' optimizations which cannot be used with C are compensated for.

> Compilers tend to be designed to support and optimize certain classes
> of program, and alas embedded applications are seldom among them.
> (that's for "generic" compiler technology.  And "computer science"
> as applied to compilers.  And education.  It's certainly possible
> that any given vendor has managed to figure out how to optimize
> embedded applications on "typical" microcontrollers and does a very
> good job.  But I've seem enough compilers do enough stupid things on
> enough targets that I don't trust this supposed "super optimization"
> will happen very often.

I am not sure whether vendors are the manufacturers of the best compilers.
Vendors sell silicon first, and unoptimized compilers sell more silicon. This is
a little evil to say but it's true. The only push factor is competition, in the
form of a better compiler supplied by a competing vendor, or by a free compiler
(like sdcc or gcc) which would make the vendor's tools look bad if they would
not be able to do more than them.

F.ex. I have difficulty to understand vendors who make Windows-only tools (which
often have a cheezy look+feel), and sometimes even want money for them.

Peter P.


2007\03\13@053853 by William Chops Westfield

face picon face

On Mar 13, 2007, at 2:18 AM, Peter P. wrote:

>> My university compiler class included only a tiny bit about code
>> generation, and most of that was aimed at a "theoretical" machine.
>
> The 'Dragon' book ('Compilers' - Aho, Sethi, Ullmann), which is
> supposedly about compiler writing (and a standard university text
> for that) is so abstract that one needs 2-3 additional books to
> be able to complete a simple compiler based on it.

That was our text.  Without the additional books.  I never did
complete the final project for that class (making it the only
class I ever flunked.  Not a requirement for EEs, though.)  Some
years later I realized that the one-line function compiler subroutine
I wrote as a fortran subroutine for playing with 3d-graphics might
have qualified as the final project, even if it didn't implement
the fancy recursive parsing.  It had actual code generation.

>
>> It's certainly possible that any given vendor has managed to figure
>>  out how to optimize embedded applications on

> I am not sure whether vendors are the manufacturers of the best
> compilers.  Vendors sell silicon first

Actually, I meant COMPILER vendors here...  There are compiler
vendors that specialized in compilers for microcontrollers (hi-tech
comes to mind) that may be off in useful directions WRT optimization
DIFFERENT than gcc, greenhill, and the other "big iron" compiler
vendors.

BillW

2007\03\13@072400 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: KILLspampiclist-bouncesKILLspamspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu]
>On Behalf Of Byron A Jeff
>Sent: 10 March 2007 22:48
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] Why bother with Assembly?
>
>
>Again debatable. Simple example: Write code that clears bit 6
>of variable i. Not so easy in standard C. Something like:
>
>   i &= ~(1<<6);
>
>Whereas PIC assembly has the more straightforward:
>
>   bcf   i,6
>

I'll just correct that for you :-)

BANKSEL(i)
bcf i,6

The elimination of manual bank/page switching is proabably one of the greatest advantages of a HLL on the PIC.

The other point is that it's very easy to choose trivial examples that seem easier in assembly, to someone famiiliar with C the bitmask example will probably make more sense, and if you make the operation a little more complex, e.g. i *= 10; then the C becomes orders of magnitude more simple to read and maintain.

That said I really enjoy using PIC assembly for smaller projects. The instruction set is small enough to remember easily and it gives my grey matter some much needed exercise figuring out the most efficient way  to code something.  It also gives a nice sense of achievement when you pack a lot of functionality into just a handfull of lines of assembly.

As most real programmers know, you choose the correct tool for the job, sometimes it's C, sometimes assembly and other times something different again.

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

2007\03\13@075056 by Rikard Bosnjakovic

picon face
On 3/13/07, William Chops Westfield <spamBeGonewestfwspamBeGonespammac.com> wrote:

> > i &= ~(1<<6)
> >
> If that's slower than i=0xBF, then you need a new C compiler.
> Math on constants can and should be done at compile time.

Yes, but i above is not a constant. Therefore the compiler won't know
if i is 242 on the first run and 4711 on the second, and it should
therefore not evaluate the whole expression (just the rightmost part).

--
- Rikard.

2007\03\13@093229 by Tamas Rudnai

face picon face
I think he meant to write i &= 0xBF instead and therefore meant that ~(1<<6)
is constant, not i :-)

Tamas


On 3/13/07, Rikard Bosnjakovic <TakeThisOuTrikard.bosnjakovicEraseMEspamspam_OUTgmail.com> wrote:
{Quote hidden}

> -

2007\03\13@105838 by wouter van ooijen

face picon face
> University does not teach
> practical things (notice that I do not have a degree ...).

Hence I must have been lost when I attend the university class about the
various forms of pattern-matching code generators...

> gcc and sdcc are free compilers whose most important merits
> are that they exist

GCC has some merits beyond that, like being on par with most commercial
compilers (at least, when compared on equal grounds).

Wouter van Ooijen

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



2007\03\13@115836 by William Chops Westfield

face picon face

On Mar 13, 2007, at 7:58 AM, wouter van ooijen wrote:

> GCC has some merits beyond that, like being on par with most
> commercial compilers (at least, when compared on equal grounds).

Yes.  And furthermore, it was SO much better than its predecessor
in the microcomputer space ("portable C compile", IIRC?)  And before
that there just weren't many C compilers.  (hmm.  Hard to believe
that gcc is almost 20years old these days.)

BillW

2007\03\13@144826 by James Newtons Massmind

face picon face
> > Um.  Maybe.  Too often compilers are written by compiler
> experts who
> > AREN'T experts in the assembly language of the target
> processor.  My
> > university compiler class included only a tiny bit about code
> > generation, and most of that was aimed at a "theoretical"
> machine.  (I
> > wasn't very impressed, being an assembly programmer at the time.)
>
> The 'Dragon' book ('Compilers' - Aho, Sethi, Ullmann), which
> is supposedly about compiler writing (and a standard
> university text for that) is so abstract that one needs 2-3
> additional books to be able to complete a simple compiler
> based on it. The 'Interpretation of Computer Languages'
> (Abelman etc - the LISP book) has a similar problem,
> excepting for the fact that LISP is interpreted so there is a
> little bit of code to work with. University does not teach
> practical things (notice that I do not have a degree ...).

Best I've seen was
http://compilers.iecc.com/crenshaw/ I REALLY enjoyed reading that. Wish I
had seen it years earlier.

---
James.


2007\03\13@151107 by wouter van ooijen

face picon face
> Best I've seen was
> http://compilers.iecc.com/crenshaw/ I REALLY enjoyed reading
> that. Wish I had seen it years earlier.

I'd recommend "A Retargetable C Compiler: Design and Implementation"
portal.acm.org/citation.cfm?id=555424&dl=acm&coll=&CFID=15151515&
CFTOKEN=6184618

Or: get the Jal source and study it :)

Wouter van Ooijen

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




2007\03\13@172537 by Peter P.

picon face
Peter P. <plpeter2006 <at> yahoo.com> writes:

> it. The 'Interpretation of Computer Languages' (Abelman etc - the LISP book)
> has

Of course that was a little brainf**t that nobody noticed. It's actually called
'Structure and Interpretation of Computer Programs', and it's Abelson and
Sussman (not Abelman). The entire book is on the web (no more excuses for not
learning LISP):

 http://mitpress.mit.edu/sicp/

The 'Dragon Book'(s) is(are - it's normal for dragons to have multiple heads
<g>) also (partial):

 http://en.wikipedia.org/wiki/Dragon_book

The C compiler I referred to is also available (compiles for win32):

 http://www.openwatcom.org/index.php/Main_Page

(Xwisp2 is implemented using this compiler)

Peter P.


2007\03\13@224332 by John Chung

picon face

--- wouter van ooijen <wouterEraseMEspam.....voti.nl> wrote:

> > Best I've seen was
> > http://compilers.iecc.com/crenshaw/ I REALLY
> enjoyed reading
> > that. Wish I had seen it years earlier.
>
> I'd recommend "A Retargetable C Compiler: Design and
> Implementation"
>
portal.acm.org/citation.cfm?id=555424&dl=acm&coll=&CFID=15151515&
> CFTOKEN=6184618
>
 I second that. Still you need some computer theory
knowledge there.

John



____________________________________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/

2007\03\14@025421 by William Chops Westfield

face picon face
On Mar 13, 2007, at 12:11 PM, wouter van ooijen wrote:
>
> Or: get the Jal source and study it :)
>
Huh.  You know, I really wish my education had included more
study of "known  working" source code from elsewhere.  I'm not
sure where it would have fit in timewise, but it would have
been both a useful skill AND useful for understanding the topics.
(in fact, I was known to use knowledge from external sources
when give those open-ended assignments like 'design a file system'
anyway, but I was never sure whether that was a good idea...)

BillW

2007\03\14@124508 by Walter Banks

picon face
Bill  (Westfield and others)

Have raised plenty of points.

I am going to have a Myth buster shot at embedded compilers. As a company we have written a bunch of compilers  most used in high volume embedded applications.

The fundamental books haven't changed for compilers, but (and its a big one) almost all undergraduate compiler courses are so focused on parsing issues they tell students that code generation is something on the back end that needs to be done later. In
embedded systems at any scale, all of the work is optimization (the part they said you can do later).

> "Too often compilers are written by compiler experts who AREN'T experts in the assembly language of the target processor."

The first real embedded systems compiler myth: Current competitive embedded systems compilers are written by people with a full understanding of the compete instruction set (Every last instruction
including those few have ever figured out how they work)


Busted if you want an embedded guy they will know about the processor


"Optimization  is magic but  my professor left optimization as an exercise for the class after the course. (He forgot to tell us what the references were and didn't leave some of the magic beans,  two part passwords or eureka moment of instant
simplification )"

The second myth is, there is no magic bean for optimization. Optimization is a lot of attention to detail. Did I say a lot? It is a lot even more than that. There are things that you can do that helps the process. Writing the compilers you learn early
about the simple things like identities (-n -1 = ~ n) early on and data flow later. The GCC "intermediate code" matches to the architecture of many common microcontrollers issues are an example of not paying the dues for attention to detail to get
results.

Busted : Optimization results comes out of hardwork and very good attention to detail. 20 years after the first embedded compiler we are still finding ways to optimize code for that processor


Myth three "A good assembly programmer can match even the best compiler"  Probably given enough time and resources. Compilers do several things well that assembly language programers cannot easily compete with for example  Compilers do well at accounting,
tracking temporary variables and reusing resources without interference. Modern compilers can use strategy passes to make choices for every application program equivalent to re-writting an application from scratch every time. Compilers use address
specific optimizations regularly that are so tough to maintain that I have seen only two or three pieces of production assembly code that uses this approach.

Compilers generate better code now in non trivial applications than most assembly programmers and generally much better resource management. With C standards for embedded systems it is now provable to be able to write anything in C in the same size that
the code can be written in assembly.

Busted, practically, will always be possible given enough resources to beat a compiler in assembly, probably also possible to beat the assembler programmer after (s)he is done with the same compiler.

I agree with one of the other comments that silicon vendors generally do not do too well with code generation. The reason seems to be around instruction set usage. Silicon vendors tend to not see their instruction set as abstract as others see it. They
work hard on achieving a silicon solution for some particular bothersome problem and tend to use the solution (because they are very familiar with it) rather than the best solution for each of the implementation problems.

w..



>


2007\03\15@030545 by wouter van ooijen

face picon face
> Myth three "A good assembly programmer can match even the
> best compiler"  Probably given enough time and resources.

My wording: An assembly programmer can outperform a compiler given
enough time. Can you recall the last time your boss gave you enough time
for a job?

Wouter van Ooijen

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



2007\03\15@185255 by Gerhard Fiedler

picon face
wouter van ooijen wrote:

>> Myth three "A good assembly programmer can match even the
>> best compiler"  Probably given enough time and resources.
>
> My wording: An assembly programmer can outperform a compiler given
> enough time. Can you recall the last time your boss gave you enough time
> for a job?

... or between changes? :)

Gerhard

2007\03\15@192808 by James Newton, Host

face picon face
> > Myth three "A good assembly programmer can match even the best
> > compiler"  Probably given enough time and resources.
>
> My wording: An assembly programmer can outperform a compiler
> given enough time. Can you recall the last time your boss
> gave you enough time for a job?
>
> Wouter van Ooijen


There have been some good points made in this thread, both one way and the
other. May I make a suggestion? Could someone (I just don't have time)
collect all the best point one way and the other and then put together a
complete list and send it to me? I'll put it up as a page on PICList.com and
then the next time someone asks this question (next week probably) we can
all just post a link to the page and avoid re-hashing it YET again?

---
James Newton: PICList webmaster/Admin
EraseMEjamesnewtonspampiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com


2007\03\15@222133 by James Nick Sears

flavicon
face
Good idea.  Set up a wiki, perhaps?

-n.

-----Original Message-----
From: "James Newton, Host" <RemoveMEjamesnewtonEraseMEspamEraseMEpiclist.com>
To: "'Microcontroller discussion list - Public.'" <RemoveMEpiclistspam_OUTspamKILLspammit.edu>
Sent: 3/15/2007 7:28 PM
Subject: RE: [EE]: C, assembly, other languages

> > Myth three "A good assembly programmer can match even the best
> > compiler"  Probably given enough time and resources.
>
> My wording: An assembly programmer can outperform a compiler
> given enough time. Can you recall the last time your boss
> gave you enough time for a job?
>
> Wouter van Ooijen


There have been some good points made in this thread, both one way and the
other. May I make a suggestion? Could someone (I just don't have time)
collect all the best point one way and the other and then put together a
complete list and send it to me? I'll put it up as a page on PICList.com and
then the next time someone asks this question (next week probably) we can
all just post a link to the page and avoid re-hashing it YET again?

---
James Newton: PICList webmaster/Admin
RemoveMEjamesnewtonTakeThisOuTspamspampiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com


2007\03\15@230754 by Tobias Gogolin

picon face
! Wiki Good !!!

I was thinking isn't it curious that in the old days OS kernels and stuff
where written in assembly language and that they have died out being
replaced by OSes written in higher level languages like C++

If there is anybody in charge of a team writing an OS and the profiler says
that something is not optimal in tight code loops then they rather invest in
optimizing the compiler then optimizing the code! Reason is clear: the
improving the tool will improve the result throughout the project...
Investing just in any section of code (by placing inline assy instructions)
lasts until the code is replaced someday...

Actually the Object Oriented aspect, as it usually results in better more
intuitive product behaviour, has not been touched on much in this thread!


On 3/15/07, James Nick Sears <EraseMEjnsearsspamspamspamBeGonejamesnsears.com> wrote:
>
> Good idea.  Set up a wiki, perhaps?
>
> -n.
>
> {Original Message removed}

2007\03\15@231348 by James Newton, Host

face picon face
AAAAAARRRRGGGGGGGGGGGGG!!!!!!!!!!

Sorry....

Please pretend you didn't hear that...

Ahem...

PICList.com IS a wiki. "the little form at the bottom of each page allows
one to add comments, questions, or code to the page. If the page is not
currently owned, you can take it as your own and edit the entire contents"

Grumble... Just because it doesn't LOOK like wikipedia...

---
James Newton: PICList webmaster/Admin
RemoveMEjamesnewtonKILLspamspampiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com




> {Original Message removed}

2007\03\15@234750 by James Nick Sears

flavicon
face
OK wise guy, then set up a page on the wiki, perhaps.

-n.

-----Original Message-----
From: "James Newton, Host" <jamesnewtonSTOPspamspamspam_OUTpiclist.com>
To: "'Microcontroller discussion list - Public.'" <spamBeGonepiclistSTOPspamspamEraseMEmit.edu>
Sent: 3/15/2007 11:13 PM
Subject: RE: [EE]: C, assembly, other languages

AAAAAARRRRGGGGGGGGGGGGG!!!!!!!!!!

Sorry....

Please pretend you didn't hear that...

Ahem...

PICList.com IS a wiki. "the little form at the bottom of each page allows
one to add comments, questions, or code to the page. If the page is not
currently owned, you can take it as your own and edit the entire contents"

Grumble... Just because it doesn't LOOK like wikipedia...

---
James Newton: PICList webmaster/Admin
KILLspamjamesnewtonspamBeGonespampiclist.com  1-619-652-0593 phone
http://www.piclist.com/member/JMN-EFP-786
PIC/PICList FAQ: http://www.piclist.com




{Quote hidden}

> -

2007\03\16@020428 by William Chops Westfield

face picon face

On Mar 14, 2007, at 10:42 AM, Walter Banks wrote:

> The second myth is, there is no magic bean for optimization.
> Optimization is a lot of attention to detail. Did I say a lot?
> It is a lot even more than that. There are things that you can
> do that helps the process.

My impression is that by this time, you can probably find quite a
bit of educational material on the sorts of optimizations that take
place at or above the "intermediate code" level like loop unrolling
and constant expression extraction, and a fair amount of stuff about
things applicable to generic processor architectures like peephole
optimization or register allocation, and there's probably even a
significant amount covering some of the nastier features of todays
flagship RISC processors, like branch optimization and multiple
functional unit scheduling.  But get to something like "efficient
implementation of boolean expressions using bit set/clear instructions"
or "efficient math on CPUs with single accumulators", and there's a
lot less coverage.  It's just not where the money is (research wise.)

BillW

2007\03\16@085005 by Walter Banks

picon face


William Chops Westfield wrote:

{Quote hidden}

A lot of the academic material is devoted to demonstrating how
badly written code can be processed to produce better or tighter
code. Most embedded programmers actually write quite good
code. Bill's right, register allocation doesn't make much sense
when a processor has only one register.

An example of the kind of things that are important in a PIC are the
tradoff between conditional branches and logical expressions.
Conditional branches are generally more efficient when no ROM
memory management is needed but the tradeoff changes as we use
larger parts in the same family because more often a conditional
branch will also need memory management.

The PIC's have lots of unique problems, compiler optimizers are data
bases of solutions that get applied where appropriate

w..






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