AVR-Chat

David Kelly wrote:
> On Oct 26, 2005, at 7:18 PM, Dave Hylands wrote:
> 
>>>Interesting idea, I think in this case the table lookup would be the
>>>preferable way to go (no real memory constraints and constant  
>>>time, but I
>>>think I'll keep a binary tree comparison in mind for possible  
>>>future use.
>>>Always more than one way to skin a cat…  Thanks again.
>>
>>Yeah - if the states values are "dense" (i.e. values like 0, 1, 2, 3,
>>4, ...) then the lookup table will be faster and take up less memory.
>>If you're implementing something where the states are "sparse" (i.e.
>>values like 1, 17, 23, 24, 51) then using the binary search method
>>would be better.
> 
> 
> Is there any good reason the states have to be sparse? If there is  
> nothing between 1 and 17 then just mark 17 as 2...
> 
> Had one spent much time with a Microchip PIC16F87x one would be  
> fluent in calculated jump tables as that is the only way to read an  
> array of data from code space. No kidding, "ABCDE" translates into  
> "RET A", "RET B", ... "RET E" and to get the Nth entry one JSRs to  
> code immediately prior which adds the index to the program counter  
> causing a skip to the return containing the desired data.

Oh, the memories!

I have a fried PIC16C55 in my desk. It was used in a project where much 
of the first 256 words of program space consisted of text strings, data 
constants, and subroutines used by the remainder of the 512 words total 
program space. The processor had a 9 bit wide stack, 1 deep, but JSR 
could only use an 8 bit wide address, so it could only JSR into the 
first 256 words.

The chip used UV erasable EPROM, so there is a window on it that shows 
the four hunks of Si in all their glory. It is fun pulling it out of my 
desk to show people what a complete computer looks like.

John