Hi John,

I read the note on jump tables from the first URL :

>
http://courses.ece.uiuc.edu/ece398/ssl/mps/mps.html

I agree, an array of function pointers whether in RAM or FLAH, would be a jump
table
(of course the note was specific to 32 bit, hence applies to another
architecture).

But that does not imply that the "jump table" - regardless of C or ASM
-
for other purposes is excluded ?
Nor does it imply IMO that function pointers are/must be involved.....

I think this issue might be more about semantics, and
terminology/interpretation.
This seems all too frequent in many fields.

-- Kris

Richard,

> I am not touching this thread with a 10 foot pole
:-) but CCS 
> is the PIC 
> compiler company. CCE is the new TI "I want to build a 
> empire" MSP430 C 
> compiler.

Cowardice in the face of the enemy, Richard?  ;-)

CCE has had a nice cosmetic makeover.  But only cosmetic...

-- Paul.

microbit wrote:

CCE      Code Composer Essentials.

>Hi John, Paul, Al et al,
>
>After observing this thread for a while , I found things were getting :
>1.    Too silly
>2.    At times inaccurate wrt "facts".
>3.    Opinion prone, rather than exact.
>
>But first I have a question :
>
>Who is CCE ?
>Is that the same company that sold its PIC compiler to Microchip
>(which truly was the shittiest compiler I'd ever seen). It may have
been CCS ?
>It would be great so I can get my own "facts" on this straight.
>
>Some of the topics discussed are opinion-prone, IMO (if that makes sense) :
>
Everything discussed here is opinion prone

>>It is probably helpful to the group to discuss
what a jump table is.
>>    
>>
>
>I think since this is an MSP430 group, that the term "symbolic
addressing mode"
>is much more appropriate.
>
>  
>
>>Both Paul Curtis and Al have made mistakes. Paul Curtis gave an
>>example of disassembly code produced from CrossWorks which was
>>conditional code that jumped. It was not unconditional jump table code
>>and it is inaccurate to state or imply it was it was jump table code.
>>    
>>
>
>Maybe I wasn't privy enough to the origin of this claim, but I
don't
>see why jump table code must be "unconditional".
>If it were, what would be the point of having a "jumptable" in the
first place ?
>
>This is why I mentioned "symbolic addressing mode".
>The "jump" is actually a compound of offsetting into a literal
table (addresses)
>and then fetching a label's address, followed by a branch to that
address.
>All in one instruction.....
>I prefer to use "computed branch" instead.
>
>  
>
>>Al confused a jump table with a table that returns literal values.
>>
Eh!

The code sample I gave as an efficient jump table was:-

    ADD      R4,PC
    JMP         IS0
    JMP         IS2
    JMP         IS4

etc.

this may not quite look like a conventional jump table:_

TABLE:

    DW      IS0,IS2,IS4


    JMP      TABLE(R4)

    or

    MOV      #TABLE,R5
    ADD       R4,R5
    JMP       @R4

But it sure as shit stinks is a jump table.

>>    
>>
>
>If it applies to the switch by using a computed branch, then that'e
_exactly_ what the
>table does, the literal is the address of the appropriate CASE statement.
>Perhaps it would be better to use "Look Up Table" (LUT) , then it
is generic.
>
>Consider this switch :
>
>i = 0 ;
>switch ( num )
>    {
>    case 0 : i++ ;
>    case 1 : i++ ;
>    case 2 : i++ ;
>    case 3 : i++ ;
>    case 4 : i++ ;
>    }
>
>The higher the value of <num> is, the lower <i> will be.
>
>I used such a switch once in an expression precedence evaluator, but then
replaced it with :
>
>  
>
>>First the concept of a jump table is well understood in computer
>>science. Below are three web site links from computer science oriented
>>sites where jump tables are mentioned.
>>http://courses.ece.uiuc.edu/ece398/ssl/mps/mps.html
>>http://condor.depaul.edu/~slytinen/373/l5.html
>>http://www.cs.helsinki.fi/u/kuuppelo/tito/k2005/laskuharj/exercise4.ht
>>ml
>>    
>>
>
>Thanks John, I will check these out myself.
>
>  
>
>>In computer science two ways of branching are considered: using
>>conditionals or using jump tables.
>>
This is mumbo jumbo. A classic jump table uses conditional, except a 
traditional conditional branch has 2 possible results, take branch X or 
continue. A multiple choice jump table says if condition is x take this 
branch , else if condition is y talke that branch. there still exists a 
conditional value. This has been so since before computer science became 
the name of a uni course.

>> In standard C conditional branching
>>is achieved with if/else statements and with switch statements. While
>>a switch statement is written as if it is jump code, it always appears
>>to be implemented as conditional if/else type code. 
>>    
>>
>
>Not true.
>Most MSP430 C compilers will pick what's most efficient according to
the
>settings (speed vs. size). (and I doubt any ASM programmer will beat it).
>
For what? Speed or size? In a typical MSP430 jump table, ie add x,pc, 
there is nothing beatable in the simple format, however in most C 
compilers it seems that registers are reserved for comp[iler use. In 
that case it is easy to beat the compiler by using egisters for the 
conditional values. However I maintain that a compiler can't look down 
those branches and see savings that an assembler programmer can.

Al



>  
>

Hi Al,

> >Some of the topics discussed are
opinion-prone, IMO (if that makes sense) :
> >
> Everything discussed here is opinion prone

I meant : semantics/opiinions vs. eg. irreducable laws of physics.

> This is mumbo jumbo. 

Another way of describing what I implied above !

> >> In standard C conditional branching
> >>is achieved with if/else statements and with switch statements.
While
> >>a switch statement is written as if it is jump code, it always
appears
> >>to be implemented as conditional if/else type code. 
> >>    
> >>
> >
> >Not true.
> >Most MSP430 C compilers will pick what's most efficient according
to the
> >settings (speed vs. size). (and I doubt any ASM programmer will beat
it).
> >
> For what? Speed or size? 

Both.
If eg. the setting is for code size, and there are few case statetements, then a
decision tree ought to be opted.
If there were lots of case statements, the compiler ought to go for computed
branch,
regardless of speed - it's faster and denser anyway.
It will of course mostly (implied) depend on the ACTUAL values of the CASE
statements.

> In a typical MSP430 jump table, ie add x,pc, 
> there is nothing beatable in the simple format, however in most C 
> compilers it seems that registers are reserved for comp[iler use. 

I see what you're saying Al, but it's a different view of the
"big picture".
Registers R12-R15 are typically scratch. Things are stored in RAM whether
ASM or C. you need to bering them in, operate on them, and store back to RAM
A good C compiler does just as good a job of that as you would in ASM.
This only applies to specific coding issues.
I've had times where - in ASM - I used a scratch register, and nested 
a call to another function (erroneously) using the same scratch register 
(hence overwrite, broken).
That's where you mainly save lost of code, but it takes a lot of effort to
track what to push/pop
and what not in ASM before you see drastic results.
I love doin the same job in C, and not having to worry about little snakes
like that biting me in the bum.


> In that case it is easy to beat the compiler by
using egisters for the 
> conditional values. 

A C compiler can do that too ...
Do bear in mind we were specifically talking SWITCH statements here Al.

> However I maintain that a compiler can't look
down 
> those branches and see savings that an assembler programmer can.

Sure.
But I conversely maintain that there might be dozens of optimisations done in
the blink
of an eye that an ASM programmer not would have done, unless he/she spent
enormous
effort identifying them, let alone implementing them.
A really simple example would be the Carry flag setting vs. clearing on a PIC
when using
add vs. sub. In pure ASM it's woeful....
Soon enough it's irrevocable that in ASM more and more macros will be
created.
Deployment of those macros can mean that the ASM programmer is somewhat
abstracting,
and hence maybe is compromising his code just as much one fine day.
You yourself claim you re-use heaps of your own ASM libs. These libs you use
possibly couldn't suit every
app 100% optimised at all times.
IMO C vs ASM is the same.
With small apps, if I spend enough time on it, I can write something in C that
will be unbeatable in ASM.
But I will have to know the compiler very well, and spend excessive time on it,
by then I'd probably have been better off
to write it in ASM in the first place ?
So I guess it's quid pro quo.
(And as Kath said in "Kath and Kim" : "... Well, this pro
isn't giving you a quid.." :-)

Well, we've ended up in old territory, oops.

Again, Al, I was specifically addressing switch statement wrt jumptable issues
in C, that's all.
And after all supporting that your supposed use of a "literal table"
was out of context (I think)

B rgds
Kris








> 
> Al
> 
> 
> 
> >  
> >
> 
> 
> 
> .
> 
> 
> 
> 
> 
> --------
> . 
> 
> 

--- In msp430@msp4..., "microbit" <microbit@c...> wrote, in

part:
> After observing this thread for a while , I found things were 
getting :
> ...
> 3.    Opinion prone, rather than exact.
> 

Then, he went on to say:
"...which truly was the shittiest compiler I'd ever seen..."
"...Most MSP430 C compilers will pick what's most efficient according 
to the  settings (speed vs. size). (and I doubt any ASM programmer 
will beat it)...."

These quotes (and other statements in the response) sure sound like 
opinions to me.  Make up your mind.  :)  At least this far-ranging 
thread is on-topic.

Lee

Hi Frudbog,

> Then, he went on to say:
> "...which truly was the shittiest compiler I'd ever seen..."
> "...Most MSP430 C compilers will pick what's most efficient
according 
> to the  settings (speed vs. size). (and I doubt any ASM programmer 
> will beat it)...."
> 
> These quotes (and other statements in the response) sure sound like 
> opinions to me.  Make up your mind.  :)  At least this far-ranging 
> thread is on-topic.

Note I annunciated at the beginning of discussion :

> Some of the topics discussed are opinion-prone,
IMO (if that makes sense) :

The (3) reference to opinion-prone was not a standalone statement, it was one of
3
descriptions.
This was meant to point out that the reference to "the switch variant"
was completely 
inaccurate (fact - not - opinion).
IOW, it was 1 of 3 facets, a pars pro toto - NOT- a totum pro parte.
(if you have enough literature knowledge, if not look it up)

Because I mentioned that the 2 are concurrently used in a where fact should not
be
replaced by opinion doesn't imply I'm not entitled to my opinions.
Are you retarded or something like that ?

-- Kris

microbit wrote:

>Hi Al,
>
>  
>
>>>Some of the topics discussed are opinion-prone, IMO (if that makes
sense) :
>>>
>>>      
>>>
>>Everything discussed here is opinion prone
>>    
>>
>
>I meant : semantics/opiinions vs. eg. irreducable laws of physics.
>  
>
I have a friend who has more degrees than I care to think of, including 
electronics, he also has a PhD in Physics, Everything he designs is 
designed precisely to the laws of physics. Nothing he designs works 
first time

>
>>>Not true.
>>>Most MSP430 C compilers will pick what's most efficient
according to the
>>>settings (speed vs. size). (and I doubt any ASM programmer will beat
it).
>>>
>>>      
>>>
>>For what? Speed or size? 
>>    
>>
>
>Both.
>If eg. the setting is for code size, and there are few case statetements,
then a
>decision tree ought to be opted.
>If there were lots of case statements, the compiler ought to go for computed
branch,
>regardless of speed - it's faster and denser anyway.
>It will of course mostly (implied) depend on the ACTUAL values of the CASE
statements.
>
>  
>
>>In a typical MSP430 jump table, ie add x,pc, 
>>there is nothing beatable in the simple format, however in most C 
>>compilers it seems that registers are reserved for comp[iler use. 
>>    
>>
>
>I see what you're saying Al, but it's a different view of the
"big picture".
>
There is no big picture. Outside of the mundane, I believe that I can 
always beat a compiler on this sort of issue

>Registers R12-R15 are typically scratch. Things are
stored in RAM whether
>ASM or C. you need to bering them in, operate on them, and store back to RAM
>A good C compiler does just as good a job of that as you would in ASM.
>This only applies to specific coding issues.
>I've had times where - in ASM - I used a scratch register, and nested 
>a call to another function (erroneously) using the same scratch register 
>(hence overwrite, broken).
>
That's not an asm or C issue, it's an organic peripheral
failure. I 
often allocate registers to function globally, or in large local chunks, 
but I don't nest them, unless it's avoidable. This isn't what I
was 
getting at though. When I create a jump table, even in the basic form of 
the MSP, using add to PC. I can look further than the compiler, because 
I understand the next operation downstream, and the one beyond that, if 
any, and work that into my optimisation. It may be, for example, that 
allocating a different bit or value allows me to change the order of the 
table and eliminate an entire function. e.g.

    ADD         R4,PC
    JMP            IS0
    JMP            IS2
    JMP            IS4

It may be that the function executed at IS2 is quite complex, but exists 
somewhere esle in the code, beyond the reach of a jmp. However by 
re-ordering IS2 and IS4 I can perhaps use a Branch at IS2, saving me 
duplicating an entire function. Could a compiler pull that out of a jump 
table? Perhaps they can, this is a simple example.

>That's where you mainly save lost of code, but
it takes a lot of effort to track what to push/pop
>and what not in ASM before you see drastic results.
>I love doin the same job in C, and not having to worry about little snakes
>like that biting me in the bum.
>
>
>  
>
>>In that case it is easy to beat the compiler by using egisters for the 
>>conditional values. 
>>    
>>
>
>A C compiler can do that too ...
>Do bear in mind we were specifically talking SWITCH statements here Al.
>
See above, we were actually talking jump tables, switch statements were 
given as the C example for generation of them. My statement ois that 
there is more to a jump table than the table itself.

>
>  
>
>>However I maintain that a compiler can't look down 
>>those branches and see savings that an assembler programmer can.
>>    
>>
>
>Sure.
>But I conversely maintain that there might be dozens of optimisations done
in the blink
>of an eye that an ASM programmer not would have done, unless he/she spent
enormous
>effort identifying them, let alone implementing them.
>A really simple example would be the Carry flag setting vs. clearing on a
PIC when using
>add vs. sub. In pure ASM it's woeful....
>Soon enough it's irrevocable that in ASM more and more macros will be
created.
>
Why? I don't use macros.

>Deployment of those macros can mean that the ASM
programmer is somewhat abstracting,
>and hence maybe is compromising his code just as much one fine day.
>You yourself claim you re-use heaps of your own ASM libs. These libs you use
possibly couldn't suit every
>app 100% optimised at all times.
>
Of course, especailly when I trade micros, but they are easily optimised 
for the current task.

>IMO C vs ASM is the same.
>With small apps, if I spend enough time on it, I can write something in C
that will be unbeatable in ASM.
>But I will have to know the compiler very well, and spend excessive time on
it, by then I'd probably have been better off
>to write it in ASM in the first place ?
>So I guess it's quid pro quo.
>(And as Kath said in "Kath and Kim" : "... Well, this pro
isn't giving you a quid.." :-)
>
Talkign about kath and Kim, true story, yesterday we were shopping at 
Woolies in a local shopping centre, I went through the express lane, 
just having some grapes, after ringing up the goods the cashier asked 
"would you like in in a bag sir", before the brain had fully engaged I

replied "No, I'd prefer it in a tent!", she just looked at me
strangely.

>
>Well, we've ended up in old territory, oops.
>
>Again, Al, I was specifically addressing switch statement wrt jumptable
issues in C, that's all.
>And after all supporting that your supposed use of a "literal
table" was out of context (I think)
>
The literal table more resembles a jump table than does a c function 
pointer table, especially since it can be coded as a jmp isntruction on 
the MSP430.

Cheers

Al

>
>B rgds
>Kris
>
>
>
>
>
>
>
>
>  
>
>>Al
>>
>>
>>
>>    
>>
>>> 
>>>
>>>      
>>>
>>
>>.
>>
>>
>>
>>
>>
>>--------
>>. 
>>
>>
>>    
>>
>
>
>
>
>
>.
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>

Hi Al,

This is a moment to maybe have  bit of "Yumour".

> >(And as Kath said in "Kath and Kim"
: "... Well, this pro isn't giving you a quid.." :-)
> >
> Talkign about kath and Kim, true story, yesterday we were shopping at 
> Woolies in a local shopping centre, I went through the express lane, 
> just having some grapes, after ringing up the goods the cashier asked 
> "would you like in in a bag sir", before the brain had fully
engaged I 
> replied "No, I'd prefer it in a tent!", she just looked at
me strangely.

Heh. I had a feeling in me waters.
I recently bought Series 3 DVD of Kath and Kim , and it's got Prue and
Trude
appearing on "The Panel" (missed out). Now I've got Series 1,2
& 3.
So I heard on that Panel episode that "next year" (which is sometime
this year) 
Kath & Kim will start in the UK. (BBC 2 bought it).

I have my funny moments too like :

-    When a storeclerk asks "how are you", sometimes I'll reply -
to their consternation -
     " completely crap".
      I always have a laugh and tell them it must be a change for them to hear
that,
      and after all, they asked how I felt !!!
-    The teller at Westpac always asks me "How would you like it ?"
when I draw
      petty cash. Sometimes I'll say "What did you have in mind
?", when I'm pretty chirpy.
      But the girls at the local bank know I'm having them on anyway, most
of them know 
      me by face.

Now I'll get back to my connubials.......

See youse all.

-- Brett

Hey, I didn't say that you offered no useful information; I
didn't 
say that anything you offered was factually incorrect.

Your post would have sttod by itself very well without the 3. 
comment.  I extracted particular pieces from your single post, and 
quoted them verbatim.  That compiler may very well be the shittiest 
ever; I don't believe that there are absolute criteria for the 
shittiest scale, so that is your opinion.  You opined that most 
MSP430 compilers would act in a particular manner.  You gave an 
opinion about >>any<< ASM programmer.

Retarded?  Another opinion in a thread in which you decried 
opinions.  Please post your criteria for retarded, and I'll see if I 
fit a sufficient number.

Lee

--- In msp430@msp4..., "microbit" <microbit@c...> wrote:
> Hi Frudbog,
> 
> > Then, he went on to say:
> > "...which truly was the shittiest compiler I'd ever
seen..."
> > "...Most MSP430 C compilers will pick what's most efficient 
according 
> > to the  settings (speed vs. size). (and I
doubt any ASM 
programmer 
> > will beat it)...."
> > 
> > These quotes (and other statements in the response) sure sound 
like 
> > opinions to me.  Make up your mind.  :)  At
least this far-
ranging 
> > thread is on-topic.
> 
> Note I annunciated at the beginning of discussion :
> 
> > Some of the topics discussed are opinion-prone, IMO (if that 
makes sense) :
> 
> The (3) reference to opinion-prone was not a standalone statement, 
it was one of 3
> descriptions.
> This was meant to point out that the reference to "the switch 
variant" was completely 
> inaccurate (fact - not - opinion).
> IOW, it was 1 of 3 facets, a pars pro toto - NOT- a totum pro parte.
> (if you have enough literature knowledge, if not look it up)
> 
> Because I mentioned that the 2 are concurrently used in a where 
fact should not be
> replaced by opinion doesn't imply I'm
not entitled to my opinions.
> Are you retarded or something like that ?
> 
> -- Kris
> 
> 
> 

Hi,

> >I meant : semantics/opiinions vs. eg.
irreducable laws of physics.
> >  
> >
> I have a friend who has more degrees than I care to think of, including 
> electronics, he also has a PhD in Physics, Everything he designs is 
> designed precisely to the laws of physics. Nothing he designs works 
> first time

I also have several degrees and soon a PhD in Physics (
http://www.nefkom.net/nobody/doct.pdf )
but only had such problems with hardware/software used outside the
specifications or the
standards or bugs in the hardware/compiler/preprocessor  (not in the design).
With the application diagrams and circuit diagrams you can google it's
usually no problem to do
a good design. But with bugs like the reset input connection in the application
diagram for the DAC1355
you are also copying old bugs in your design. 
And some things like disturbing reflections on the I2S bus, caused by the change
from a four layer PCB to
a two layer PCB, are very hard to calculate (but easy to debug e. g. with
lowpass filters).
 
Regards,

Rolf