Searching \ for 'C vs. 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: 'C vs. ASM'.

Truncated match.
PICList Thread
'C vs. ASM'
1999\11\10@095626 by jcowgar

flavicon
face
Are C compliers generally better at creating smaller .ASM code than a human,
or can someone who knows ASM create smaller .ASM code than the C compiler?

What I am trying to ask is there an advantage to using ASM since I already
know C. Once you learn a language, you can pick up others, but there is a
great learning curve, is it worth it?

Jeremy - spam_OUTKB8LFATakeThisOuTspamqsl.net

1999\11\10@103130 by Nick Taylor

picon face
Jeremy,

A _good_ programmer can create as small or smaller code with assembler
than with even a very good C compiler ... but it's more time consuming.
PIC assembler is fairly easy to learn (especially with your C
background)
because of it's small instruction set.  It also  is an excellent intro
to assembler, making it much easier to learn a more complicated MCU
later.  IMO it definitely is worth the effort.

Good luck and have fun,
- Nick -

Jeremy Cowgar wrote:
>
> Are C compliers generally better at creating smaller .ASM code than a human,
> or can someone who knows ASM create smaller .ASM code than the C compiler?
>
> What I am trying to ask is there an advantage to using ASM since I already
> know C. Once you learn a language, you can pick up others, but there is a
> great learning curve, is it worth it?
>
> Jeremy - .....KB8LFAKILLspamspam@spam@qsl.net

1999\11\10@104620 by eplus1

flavicon
face
The only way a C compiler is going to generate smaller code that hand ASM is
if the ASM experience of the guy who wrote the C compiler is well
implemented in the compiler itself AND is greater than the ASM experience of
the programmer using the C compiler. This assumes:

1) the ASM experience of the compiler writer is vast. If C compilers were
easy to modify (i.e. "hey the code this compiler generated for this set of C
statements is not nearly as efficient as my hand coded ASM, next time you
see this code, Mr. C Compiler, use this routine instead") and if everybody
who added such experience would post it for others, then may be this would
be different.

2) this experience is well implemented. The example in point 1 is just about
impossibly to implement on a large scale because the compiler would grind to
a halt under the load of matching up every possible chunk of C code with the
best ASM code from a vast library. Also, the transition from one chunk of
code to the next needs to compensate for variables being loaded in different
registers etc....

3) the experience of the programmer is (much) less than the compiler writer.
I have not seen this to be the case. They guys who write compilers are not
usually the guys who have actually touched, much less gotten good at, ASM
coding on the target processor. Anybody want to add or subtract from that
opinion?

<FLAME SUITE="ON">Learning ASM after learning C appears to be damn hard.
Learning C after learning ASM is easy, but unsatisfying. Once you know what
is really going on, you look for ways to do things faster in ASM rather than
in C.</FLAME>

Maybe its just a matter of personal style.

James Newton jamesnewtonspamKILLspamgeocities.com phone:1-619-652-0593
http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)
PICLIST guide: http://204.210.50.240/techref/default.asp?url=piclist.htm


{Original Message removed}

1999\11\10@114105 by Andy Baker

flavicon
face
My job is C programming, and I'd say it took me an evening to pick up the
instruction set well enough to start coding at a reasonably well. Ok it
wasn't the most efficient assembler at first, but it added interest to code
in something other than C.

In my opinion (which you may freely disregard), even though C is a low-level
language, it is still too high a level when the target is a lowly PIC. Most
of the PIC C code I've seen (not that much I admit) looks so like the
assembler, I do wonder why people have coughed up the cash for the compiler,
when they can't use any of C's really powerful features on the pic

Go for ASM, the challenge will be good for the brain!

Have fun,

Andy

{Original Message removed}

1999\11\10@121119 by Chris Eddy

flavicon
face
I thought we agreed, no religious wars on the list?
Fools rush in where angels fear to tread.

Seriously, you have a few variables to consider.  The type of program matters.
If you are doing alot of math, say 16 or 32 bit, it sure is convenient to do it
all in C.  I found in some of my conversions, when I picked up the HiTech
compiler, that the compiler beat me.  That is not always the case.  An
application could also rely heavily on timing and logic state machines.  These
apps tend to benefit from tight assy.  The last angle is that of style.  If you
did assy and moved over to C, you tend to use it as a pseudo language, writing
in a manner that the compiler packs efficiently.  If you only know C, and you
are coming from the PC world, your own inefficencies (which didn't matter a whit
on the PC) will haunt you deeply.

Chris Eddy
Pioneer Microsystems, Inc.

Jeremy Cowgar wrote:

> Are C compliers generally better at creating smaller .ASM code than a human,
> or can someone who knows ASM create smaller .ASM code than the C compiler?
>
> What I am trying to ask is there an advantage to using ASM since I already
> know C. Once you learn a language, you can pick up others, but there is a
> great learning curve, is it worth it?
>
> Jeremy - .....KB8LFAKILLspamspam.....qsl.net

1999\11\10@123230 by w. v. ooijen / f. hanneman

picon face
> I do wonder why people have coughed up the cash for the compiler,
> when they can't use any of C's really powerful features on the pic

To name just a few possible reasons:
- to get the job done faster (as opposed to getting faster running code)
- libraries that are available can save a lot of work
- the compiler eliminates unused code & data
- the various routines/functions/procedures share RAM
(register files) stactic-stack wise
(try to do that by hand without making errors!
Who said compilers can never outperform people?)
- because the compiler was there anyway (or costed $0) and you already
knew the language

A few arguments for the other side (why use assembler)
- because I need the last drop of performance / code density /
register file use
- because the compiler (or library) has a bug

Note that these arguments do not imply a particular compiler,
language or even target. The best option is often to use a HLL
whenever possible and use Asm for the 'difficult' parts. I have
even seen succesfull use of more than 2 levels, e.g.a mix of
Tcl/Tk, Ada, C, Assembler. Microcontroller programming often
has a much larger percentage 'difficult' code than e.g. a payroll,
but not necessarrily 100%.

Wouter

(a free compiler for those who do not object to learning yet
another language: http://www.xs4all.n/~wf/wouter/pic/jal )

PS I got no answers to this question a few days ago: can
someone point me to the DEFINITION of SPI
(Serial-Parallel Interface, not Software Process Improvement)

1999\11\10@132230 by Jason Mielke

flavicon
face
Although I would agree with you Andy that efficient C-Code starts to look a
lot like assembly, I have found it very useful in certain routines that
needed to be used in several target circuits.  For example:  a routine to
parse out 900 characters of ASCII and produce a result.  The result might go
to an LCD in one circuit or be used to light LEDs in another.  The routine
itself was written once and used repeatedly.  Might point being that the
real benefit of the C code is slightly portable libraries.
Flame Away!

Jason Mielke
Chief Engineer
Bliss Communications, Inc.
EraseMEjayspam_OUTspamTakeThisOuTticon.net

*********************************************
WCLO/WJVL    WBKV/WBWI     WFHR/WGLX     WRJN/WEZY
********************************************


> {Original Message removed}

1999\11\10@214620 by Robert M. McClure

flavicon
face
At 07:43 AM 11/10/99 -0800, James Newton wrote:
>The only way a C compiler is going to generate smaller code that hand ASM is
>if the ASM experience of the guy who wrote the C compiler is well
>implemented in the compiler itself AND is greater than the ASM experience of
>the programmer using the C compiler. This assumes:
>
>1) the ASM experience of the compiler writer is vast. If C compilers were
>easy to modify (i.e. "hey the code this compiler generated for this set of C
>statements is not nearly as efficient as my hand coded ASM, next time you
>see this code, Mr. C Compiler, use this routine instead") and if everybody
>who added such experience would post it for others, then may be this would
>be different.
>
As a compiler of some years of experience, let me assure you that not even
the most elementary of compilers is easy to modify -- and not introduce bugs
at the same time -- regardless of the ASM experience of the compiler writer.

>2) this experience is well implemented. The example in point 1 is just about
>impossibly to implement on a large scale because the compiler would grind to
>a halt under the load of matching up every possible chunk of C code with the
>best ASM code from a vast library. Also, the transition from one chunk of
>code to the next needs to compensate for variables being loaded in different
>registers etc....
>
That is not essentially the way compilers operate.  Only a few compilers have
ever been written that take more than a very local view of the code to be
generated.  Register allocation is a whole 'nother bag of worms.

>3) the experience of the programmer is (much) less than the compiler writer.
>I have not seen this to be the case. They guys who write compilers are not
>usually the guys who have actually touched, much less gotten good at, ASM
>coding on the target processor. Anybody want to add or subtract from that
>opinion?
>
This is a place that I have a major disagreement.  In my experience, most
compiler writers are very good at assembler coding.  When confronted with
a new processor, substantially all start by doing a lot of coding for the
target processor -- in assembler.  The ones who don't come largely from an
academic only background -- and their compilers are rarely any good.

><FLAME SUITE="ON">Learning ASM after learning C appears to be damn hard.
>Learning C after learning ASM is easy, but unsatisfying. Once you know what
>is really going on, you look for ways to do things faster in ASM rather than
>in C.</FLAME>
>
>
Back to agreement mode.  This is essentially a correct statement, and I
personally feel that processors of the PIC, 8051, AVR, 68HC11, ...
variety are best programmed in assembler.  This in spite of having
written compilers for quite a few processors, and most of those in C.
(I have now donned the asbestos suit while awaiting the flames.)

Bob McClure

1999\11\11@005223 by Dave VanHorn

flavicon
face
> ><FLAME SUITE="ON">Learning ASM after learning C appears to be damn hard.
> >Learning C after learning ASM is easy, but unsatisfying. Once you know
what
> >is really going on, you look for ways to do things faster in ASM rather
than
> >in C.</FLAME>

Exactly how I anticipate it will work out, when I finally learn C.
High level languages encourage you to ignore the machine, which is never
going to produce better (smaller, faster etc)  code than when you're paying
attention to everything.  Kind of like a PCB autorouter, it does the job
usually, but I can always do a better job, given a few hours, and some of
the things it does make you think it has lost it's mind..

1999\11\11@061033 by Russell McMahon

picon face
There are a few things which

- CAN'T be done in C without reference to the code it makes

or

- SHOULDN'T be done in assembler. There are no things which can be done
which can't be done in assembler but there are some shouldn'ts.

One example of each:

1. - CAN'T be done in C without reference to the code it makes

Writing isochronous code (ie code which has a constant execution time from
entry to exit regardless of path followed) requires a precise understanding
of the code which will be executed to the nearest instruction cycle. In
assembler, writing such code is possible but may be annoying. In C, unless
you know the actual code generated you CANNOT be sure how long various
portions take. Also, HLL's may change the code used depending where the code
lies within the overall program. This is true of assembler as well BUT, YOU
are in charge and responsible for the result - when the HLL is in charge it
may not tell you when it changes things.

Isochronous code is rarely essential but is often useful (and sometimes IS
essential :-))
eg a Sigma delta analog to digital converter demands constant time between
samples as an essential part of its operation. If one does not wish to use
timer interrupts for this for whatever reason then isochronous code is
needed.

2.  - Shouldn't be done in assembler.

A really optimised high level language with a good knowledge of the
instruction set of the processor can jump into the middle of multi byte
instructions to produce a different instruction. Or, it may use the last
byte (or bytes) in a data table as instructions if it is useful to do so.
( ! :-) !!!)
(Neither of these tends to apply to PICs due to their invariable 1 word per
instruction format).

I have seen the "jump into the middle of an instruction" trick done. I don't
know how common it is.
I have also seen this done in code made by what appeared to be hand coded
assembler.

When this is done by a HLL (C or whatever) it is clever, supportable and may
be useful.

When done in assembler it is
- undocumentable
- dangerous
- may stop working at any time if you don't remember you did it and
- you should instantly fire the programmer who does it if he / she ever does
it again once you have told them not to :-).

You have no chance of supporting code containing assembler generated code of
this sort.




     Russell McMahon
_____________________________

>From another world - http://www.easttimor.com

What can one man* do?
Help the hungry at no cost to yourself!
at  http://www.thehungersite.com/

(* - or woman, child or internet enabled intelligent entity :-))


{Original Message removed}

1999\11\11@092104 by Darrel Johansen

picon face
Russell McMahon wrote:
>...
> I have seen the "jump into the middle of an instruction" trick done. I don't
> know how common it is.
> I have also seen this done in code made by what appeared to be hand coded
> assembler.
>
> When this is done by a HLL (C or whatever) it is clever, supportable and may
> be useful.
>
> When done in assembler it is
> - undocumentable
> - dangerous
> - may stop working at any time if you don't remember you did it and
> - you should instantly fire the programmer who does it if he / she ever does
> it again once you have told them not to :-).
>

When done by a human using one tool it is wrong, but using another tool it's
ok?  That's contradictory, at best.  I've seen this trick only a few times and
have used it myself, but only at the assembly level.  If C code did this I
would be surprised, annoyed, and frustrated when it comes to debugging it.

The place where it IS useful and which was my introduction into the technique
was the Apple ][ monitor code, written by Steve Wozniak.  Where space is at a
premium, assembly language tricks are valuable.  If space is at a very high
price, C code probably should be avoided, as the best assembly language
programmer can always produce smaller code than the best C language programmer.

Note that this trick CAN be used (though I have yet to see it be done) on the
PIC 18Cxxx architecture.

--
___________________________
|     Darrel Johansen     |
|     tempe,  arizona     |
|   darreljspamspam_OUTprimenet.com  |
|_________________________|

1999\11\11@103221 by eplus1

flavicon
face
<BLOCKQUOTE AUTHOR="Russell McMahon">I have seen the "jump into the middle
of an instruction" trick done. I don't
know how common it is.
I have also seen this done in code made by what appeared to be hand coded
assembler.

When this is done by a HLL (C or whatever) it is clever, supportable and may
be useful.

When done in assembler it is
- undocumentable
- dangerous
- may stop working at any time if you don't remember you did it and
- you should instantly fire the programmer who does it if he / she ever does
it again once you have told them not to :-).

You have no chance of supporting code containing assembler generated code of
this sort.</BLOCKQUOTE>

I agree on your other points but... I'm glad I don't work for you <GRIN>.

I'm going to enjoy debating this. Please don't take this personally
but:<SPIN SPEED="UP">
1. How can anything not be documentable? That has got to be just plain dogma
on your part. Just a quick comment at each place where the technique is used
should warn future code maintainers as to what is going on. Add an url to
your homepage (or to the techref) for a more detailed explanation.

2. ALL code will stop working if you don't understand what it does and
modify it incorrectly.

3. Any programmer who understands that type of trick is a jewel that should
not be cast out, but instead allowed to shine on others. The only
"punishment" I would advocate is a training session for the other
programmers in the stable as to how to make use of the trick.
</SPIN>

I guess you got burned on this one and are still pissed about it? <WINK>
<WINK> <NUDGE> <NUDGE> I still can't stand to work in a company with more
than 5 employees for similar reasons; got back stabbed, can't trust
co-workers to this day.

But, seriously, I am looking forward to hearing any more valid arguments. I
do thinks its important for programmers (especially in ASM) to document
everything 'cause you don't know what the next guy hasn't got in his bag of
tricks and your not being a professional unless you care about him/her and
about your employer. Professionals also share knowledge.

James Newton @spam@jamesnewtonKILLspamspamgeocities.com phone:1-619-652-0593
http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)
PICLIST guide: http://204.210.50.240/techref/default.asp?url=piclist.htm

1999\11\11@103434 by eplus1

flavicon
face
Don't tease... how can a PIC use this trick?

James Newton KILLspamjamesnewtonKILLspamspamgeocities.com phone:1-619-652-0593
http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)
PICLIST guide: http://204.210.50.240/techref/default.asp?url=piclist.htm


{Original Message removed}

1999\11\11@160304 by Lawrence Lile

flavicon
face
Oh I can't resist getting into this one...

<Religious war armor  = ON>

1.  You can't write efficient C for a PIC unless you know ASM, and can pick
apart the generated ASM code byte by byte.

2.  I can write C that is nearly-almost-just-about as efficient as ASM, but
I never hope to beat the efficiency of ASM with any HLL.  I can also get
real sloppy and write C that takes up twice the room as ASM.  Depends on the
time/optimization tradeoff.

3.  I cannot AFFORD to write code in ASM anymore - it takes too much time.
At $35 to $65 (depressed midwest Engineers wages-Don't laugh) per hour, and
ASM taking 2 to 3 times longer (I can write both C and ASM as fast as I can
type, usually)  it just costs too much money

4.  90% of the time I can write code in C that compiles without errors the
first time through.  Never is this the case with <Hair Pulling = ON> <Teeth
Gnashing = ON>  ASM.  </Hair> </Teeth>

The short answer is, Jeremy, you'll need to learn enough ASM to figure our
what your code is doing.

</Religious war armor>

>Jeremy Cowgar wrote:
>
>> Are C compliers generally better at creating smaller .ASM code than a
human,
>> or can someone who knows ASM create smaller .ASM code than the C
compiler?
>>
>> What I am trying to ask is there an advantage to using ASM since I
already
>> know C. Once you learn a language, you can pick up others, but there is a
>> great learning curve, is it worth it?
>>
>> Jeremy - RemoveMEKB8LFATakeThisOuTspamqsl.net

1999\11\11@170022 by Wagner Lipnharski

picon face
You drive your car in "C", but you pay its maintenance in Assembler.

Your doctor search your problems in Assembler and then prescribe "C"
pills to fix you.

Your wife ask your green "C" bills to spend in the shopping in
Assembler.

All of your job description is done in "C", but you need to do it in
Assembler.

Your nice green front yard grass has a "C" view, but nobody knows how
many Assembler hours it takes to get rid of the pests and weeds.

Popcorn comes originally in "C", then it pops and turn into Assembler.

When you press the "C" Play button at your CD player, it plays in
Assembler.

Before marriage everything is "C", after is pure Assembler.

You drink "coffee" that comes from Brazil or Colombia, named "cafŽ".

If salad and legumes are good to loose weight, why cattle and vegetarian
animals are so big and fat?

You use a pocket electronic "English" dictionary that was produced in
"Taiwan".

It doesn't matter the language you use, choose the one that you can work
faster, generate smaller and faster code, and most important, make your
boss happy.  Perhaps... one can come up with PIC-Cobol Compiler... or
PIC-RPG... :)

1999\11\11@210258 by Sean Breheny

face picon face
At 04:58 PM 11/11/99 -0500, you wrote:
>Your wife ask your green "C" bills to spend in the shopping in
>Assembler.

I don't think most people would be happy if their wife asked for several "C
notes" each time she went shopping <G>

Sean

|
| Sean Breheny
| Amateur Radio Callsign: KA3YXM
| Electrical Engineering Student
\--------------=----------------
Save lives, please look at http://www.all.org
Personal page: http://www.people.cornell.edu/pages/shb7
spamBeGoneshb7spamBeGonespamcornell.edu ICQ #: 3329174

1999\11\11@210303 by Chris Eddy

flavicon
face
Hey Wagner, could you drop by?  And be sure to bring whatever it is your
smoking.  Must be REAL powerful.

Chris Eddy

Wagner Lipnharski wrote:

{Quote hidden}

1999\11\11@213033 by TIM

flavicon
face
good one chris.........wagner is kewl....tim
-----Original Message-----
From: Chris Eddy <TakeThisOuTceddyEraseMEspamspam_OUTNB.NET>
To: RemoveMEPICLISTspamTakeThisOuTMITVMA.MIT.EDU <PICLISTEraseMEspam.....MITVMA.MIT.EDU>
Date: Thursday, November 11, 1999 6:03 PM
Subject: Re: C vs. ASM


{Quote hidden}

1999\11\12@051442 by Andy David

flavicon
face
part 0 648 bytes
       >Don't tease... how can a PIC use this trick?

James,

The 18c series are the first PICs to have instructions that are > 1 word
long, hence it's possible to bypass the first word of the instruction
and execute the second on this family.

As much as I hate quoting continually from a single source, the most
reasonable argument of C/Asm can be found at:

http://pw2.netcom.com/~fastfwd/answers.html#OTHER00012

I particularly like points 5a and 5b.


- Andy.
---------------------------------------------------------
Andrew David, Software Manager, Ultronics Ltd, Cheltenham
EraseMEakdavidspamultronics.co.uk          http://www.ultronics.com


1999\11\12@131146 by eplus1

flavicon
face
That is one hell of a page! Id like to link to it from my techref's pic
page, ok?

For some constructive criticism, that page desperately needs to be
organized. Want some help?

James Newton RemoveMEjamesnewtonEraseMEspamEraseMEgeocities.com phone:1-619-652-0593
http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)
PICLIST guide: http://204.210.50.240/techref/default.asp?url=piclist.htm


{Original Message removed}

1999\11\12@132424 by John A. Craft

flavicon
face
I keep waiting for the book "Andrew Warren: I did it my way" to come
out...... :)

Jc.


At 10:08 AM 11/12/99 -0800, James Newton wrote:
{Quote hidden}

>{Original Message removed}

1999\11\12@223330 by Clyde Smith-Stubbs

flavicon
face
On Fri, Nov 12, 1999 at 10:10:38AM -0000, Andy David wrote:
> The 18c series are the first PICs to have instructions that are > 1 word
> long, hence it's possible to bypass the first word of the instruction
> and execute the second on this family.

True, but since the second word of the multi-word instructions is always
a special kind of NOP, there's not much value in jumping into the middle
of it.


--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: RemoveMEclydeTakeThisOuTspamspamhtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger EraseMEclydespamspamspamBeGonehtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

1999\11\13@065335 by Russell McMahon

picon face
>"Russell McMahon">said
>I have seen the "jump into the middle
>of an instruction" trick done. I don't
>know how common it is.
>I have also seen this done in code made by what appeared to be hand coded
>assembler.
>
>When this is done by a HLL (C or whatever) it is clever, supportable and
may
>be useful.
>
>When done in assembler it is
>- undocumentable
>- dangerous
>- may stop working at any time if you don't remember you did it and
>- you should instantly fire the programmer who does it if he / she ever
does
>it again once you have told them not to :-).
>
>You have no chance of supporting code containing assembler generated code
of
>this sort.

James Newton said -

>I agree on your other points but... I'm glad I don't work for you <GRIN>.


OK. You're fired - obviosuly intractable and won't take instruction :-)

>1. How can anything not be documentable? That has got to be just plain
dogma
>on your part.

Yep. Plain dogma. Some dogma is based on experience or sense though :-)
But see below why it REALLY isn't documentable.

>Just a quick comment at each place where the technique is used
>should warn future code maintainers as to what is going on.

No. Nothing whatsoever will protect you against its universal use.
BECAUSE -
Once you allow or encourage programmers to use parts of existing code as
portions of another instruction you officially tell them that the procedure
is controllable. Even if you say it can be done in xxx situation but not in
yyy situation you open up the possibility of them judging wrong or of the
boundary being unclear or of them just doing it bloody-mindedly (they are
people, after all) or ignorantly. (A friend of mine had a programmer who
insisted on trying to store persistent data in temporary "local" variables
stored on a stack in a subroutine. If a computer science graduate can do
that he/she can surely get confused on multi-function code.)

Here are some examples of where it will fail despite documentation warning
you about it.

- The double used code is an offset in a relative jump. Some of the code is
inserted or removed NOT AT THE JUMP LOCATION. The jump offset changes. Death
ensues.

- The double used code is part of a lookup table. The warning is inserted
either at the top of the table or at the point of actual re-use. Someone
wants to modify the table. They may even see your warning note at the
relevant point. They may make the table longer/shorter (which may or may not
kill your code depending on how it works). They may generate the table using
a new algorithm without looking at the old code because this is how it was
done before, prior to your clever use of code. They may use new table data
and misunderstand your note and leave the data the same at your location
despite its effect on the table's function. In each case Murphy will ensure
that death ensues.

- This one is most unlikely but... : The manufacturer changes the processors
code set. eg Some day,  MChip have told us, the TRIS will vanish - if you
have bodge coded the TRIS instruction then ... .

- The hand bodged instruction is clearly marked. The person-who-comes-after
does not fully understand what you are doing and respectfully leaves it
alone. BUT, the code feeds into somewhere else and because the instruction
was effectively "invisible" at the C or assembler or whatever level then
they ignore its effect when they change the following (or preceding) code.
Death ensues :-).

>2. ALL code will stop working if you don't understand what it does and
>modify it incorrectly.


Yep. This is just a superior way of ensuring that it happens :-)

>3. Any programmer who understands that type of trick is a jewel that should
>not be cast out, but instead allowed to shine on others. The only
>"punishment" I would advocate is a training session for the other
>programmers in the stable as to how to make use of the trick.


He's fired too :-)


>I guess you got burned on this one and are still pissed about it? <WINK>
><WINK> <NUDGE> <NUDGE> I still can't stand to work in a company with more
>than 5 employees for similar reasons; got back stabbed, can't trust
>co-workers to this day.


No. Never have been. But I don't want to ever have more than 6 people
working for me after having had 20+ at one stage long ago.



Someone else asked "why is this acceptable for a compiler to do but not a
person".
I say that it is MORE acceptable (but still dangerous) because the compiler
knows the full rule set it works from and builds the code up "from scratch"
on each occasion. Even this can be made to be untrue but it is reasonable
true. The biggest danger is that someone will attempt to hand optimise or
alter the code, and all bets are off.




regards,


               Russell McMahon

1999\11\13@094419 by Darrel Johansen

picon face
Clyde Smith-Stubbs wrote:
>
> On Fri, Nov 12, 1999 at 10:10:38AM -0000, Andy David wrote:
> > The 18c series are the first PICs to have instructions that are > 1 word
> > long, hence it's possible to bypass the first word of the instruction
> > and execute the second on this family.
>
> True, but since the second word of the multi-word instructions is always
> a special kind of NOP, there's not much value in jumping into the middle
> of it.

The only value in this kind of code is to save a little bit of memory.  Usually
this is hardly necessary, but in the Apple ][, where I first encountered it,
all kinds of tricks like this were used to wedge in a couple more instructions.

I imagine that someone could do a short branch (one instruction) into the
second word of a two word instruction to "roll on" to the next instruction that
was just out of range of the branch.  I'm sure there are other tricks that
might be done with it, but it's unstructured and undebuggable code, to be used
only as a last resort.  In no way do I promote it, but in special cases a very
clever coder can get more out of the machine than the original designers of the
architecture ever suspected.

___________________________
|     Darrel Johansen     |
|     tempe,  arizona     |
|   RemoveMEdarreljKILLspamspamprimenet.com  |
|_________________________|

1999\11\15@045556 by Andy David

flavicon
face
part 0 752 bytes
       Clyde's reply:

       >True, but since the second word of the multi-word instructions
is always
       >a special kind of NOP, there's not much value in jumping into
the middle
       >of it.

I guess not, but that wasn't the point ;-)

Does your C-compiler support or have plans to support the 18c family?
I'm looking at one of the 18c's for a project next year and want to use
C. I'm going to look at MPLAB-C18, but I'd really like to see what else
there is. I don't know what Bytecraft's plans are, but I hope they'll
support the family, too.


- Andy.
---------------------------------------------------------
Andrew David, Software Manager, Ultronics Ltd, Cheltenham
akdavidSTOPspamspamspam_OUTultronics.co.uk          http://www.ultronics.com

1999\11\15@055033 by Clyde Smith-Stubbs

flavicon
face
On Mon, Nov 15, 1999 at 09:53:11AM -0000, Andy David wrote:

> Does your C-compiler support or have plans to support the 18c family?

WE have an 18C compiler at an alpha stage. It will be a separate product
to the current PIC compiler, but there will be special upgrades available
for current customers.



--
Clyde Smith-Stubbs               |            HI-TECH Software
Email: spamBeGoneclydeSTOPspamspamEraseMEhtsoft.com          |          Phone            Fax
WWW:   http://www.htsoft.com/    | USA: (408) 490 2885  (408) 490 2885
PGP:   finger KILLspamclydespamBeGonespamhtsoft.com   | AUS: +61 7 3355 8333 +61 7 3355 8334
---------------------------------------------------------------------------
HI-TECH C: compiling the real world.

1999\11\15@060938 by Andy David

flavicon
face
part 0 570 bytes
       >> Does your C-compiler support or have plans to support the 18c
family?
       >
       >WE have an 18C compiler at an alpha stage. It will be a
separate product
       >to the current PIC compiler, but there will be special upgrades
available
       >for current customers.

Thanks, Clyde, that's good news. I'll watch your web site for
announcements.


- Andy.
---------------------------------------------------------
Andrew David, Software Manager, Ultronics Ltd, Cheltenham
EraseMEakdavidspamEraseMEultronics.co.uk          http://www.ultronics.com


1999\11\15@100330 by eplus1

flavicon
face
We can agree to disagree on this one. I do see some of your points and I
guess that if I had ever managed 20+ programmers I might agree more. I
totally failed to keep 3 German programmers under control once, but I blame
that on cultural differences more that anything. Not that I'm saying
anything bad about Germans, just that I'm from a different culture. The
company was (is) wildly successful, but the software was (is) pure crap.

I do agree that there are times that very tricky code is not desirable when
it must be maintained / reused by other programmers who are not as tricky.
In the best of all possible worlds, I would like all my programmers to be
equally tricky and devoted to good documentation.

Let me insert another point in your "level of acceptance of the use of this
trick" scale. I would think that a macro in ASM would be somewhere between
use in hand coded ASM and compiler use.

Also, your first example of documentation not working would seem to not be
an issue if the code was in assembler and was reassembled after the change.
You seem to be referring to a code "patch" made to the actual binary which I
suppose could be a real world occurrence.

James Newton @spam@jamesnewton@spam@spamspam_OUTgeocities.com phone:1-619-652-0593
http://techref.homepage.com NOW OPEN (R/O) TO NON-MEMBERS!
Members can add private/public comments/pages ($0 TANSTAAFL web hosting)
PICLIST guide: http://204.210.50.240/techref/default.asp?url=piclist.htm


{Original Message removed}

1999\11\15@104715 by Wagner Lipnharski

picon face
> >When done in assembler it is
> >- undocumentable
> >- dangerous
> >- may stop working at any time if you don't remember you did it and
> >- you should instantly fire the programmer who does it if he / she ever
> does
[snip]

Well, I think here we need to say that a software professional, a good
one, one that deserve this title, much before to be a software writer,
should be a "documenter".

I would dare to say that, the professionalism start by the details, and
in software, want you to agree or not, good comments in a source is not
only a must, it is imperative.

After I started to comment each single line of the assembler source, I
noticed a reduction in errors and problems, because commenting a source
is also a way to interface a machine language code to our human mind
language.

If you don't believe me, try to write two lines of not commented code
and get it ISO-9000 approved,

Probably you can find lots of software genius around that hate
commenting his/her software, ok, this is the way they do it, but it is
at least irresponsible.  It is the same as giving birth to a baby and
not identifying he/she with an Identification hospital tag... would you
be able to recognize the baby next day in middle of other 50 babies?

Probably the best way to get it done, is discount from the software
professional's monthly payment a proportional quantity in money, of the
non commented source code lines... then they will start to do it right
immediately.  You should remember that if you are the boss, or the
company's owner, you decide how the work should be done, and (I am sorry
to say this) if you are not achieving this goal, it is only *your*
fault, nobody else should be held responsible.

1999\11\15@132649 by Don Hyde

flavicon
face
I once worked with a group of ex-IBM assembler jocks.  They had a very
strict rule requiring 2 comments for every 3 lines of assembler code.

One of these guys was a  poetry buff.  The right-hand column of his listings
had neat lines of iambic pentameter.  The poetry had nothing to do with the
source code, but it was always passed by the official code-checkers.  BTW --
he was a fantastic coder and produced lots of good code in spite of all the
time he spent writing (bad) poetry on company time.

Trying to achieve good code by having simple-minded rules not only doesn't
work, but positively invites rebellious behavior from the best programmers.
It'll never turn the bad programmers into good ones, but it'll piss off the
good ones every time.

> {Original Message removed}

1999\11\19@171557 by Robert M. McClure

flavicon
face
At 12:25 PM 11/15/99 -0600, Don Hyde wrote:
>I once worked with a group of ex-IBM assembler jocks.  They had a very
>strict rule requiring 2 comments for every 3 lines of assembler code.
>
......
>
>Trying to achieve good code by having simple-minded rules not only doesn't
>work, but positively invites rebellious behavior from the best programmers.
>It'll never turn the bad programmers into good ones, but it'll piss off the
>good ones every time.
>

Yes, indeed.  IBM also trying applying metrics to programmer productivity
back in the late 1960's.  That is they kept meticulous records of the number
of lines of code produced by each programmer each month and the number of
bugs found in that code.  What they got was voluminous code with few
subroutines.  Programmers it seemed, having debugged a subroutine, would
simply copy it inline everytime they wanted to call the routine.

Bob McClure

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