link list

A linked-list is essentially a sequential access data structure; ie, you begin at one end of the list, and search through it until you find the desired entry.

A lookup table, on the other hand, is a direct access data structure; ie, you can go direct to the required entry simply by using its index.

"Now I want to implement a link list which will access the rpm from table ... Is it possible"

Of course it is possible - but I can't see any benefit in doing it!

There are many applications where linked-lists can be useful - but I really don't think this is one of them!
Why do you think this will be beneficial?
Why not just access the lookup table directly in the normal manner?

"Because as I am studying the link list, in that it is mentioned that link list is used instead of array"

Perhaps you need to study whatever source said that a bit more carefully and look at the reasons why a linked-list might be chosen instead of an array.
I don't think this is one of them.

Note that this is standard 'C' - it has nothing specifically to do with Keil, C51, or the 8051

thanx for reply Andy;
i know my project doesnot need any link list
but to study purpose i want to implement, so that i will be familier with link list
can u suggest me any link for this topic
thank u again

"Note that this is standard 'C' - it has nothing specifically to do with Keil, C51, or the 8051"

Note that most textbook examples will use dynamic memory allocation (malloc, etc) to create the entries in the list.
One of the key advantages of linked-lists is the way that the entries can be dynamically created like this - but that does not mean that they have to be dynamically created.

In fact, for embedded systems in general and the 8051 in particular, it is most likely that the entries should not be dynamically allocated!

In an embedded system, it is far more likely that you would statically create a fixed number of entries, and simply link them into either a "free" list or an "in-use" list.

www.8052.com/.../read.phtml

I have a project in which I have lookup table of rpm (clocks used to load the timer used for motor).

Linked lists are usually used for dynamic data structures, i.e. when you're adding and removing elements during the run-time of the program. I don't think that usual lookup-tables do this.

Is it possible

It's possible, but in this case it looks like the completely wrong tool for the job at hand. The linked list will take up more memory and have a longer access time than a straight lookup table using an array.

Because as I am studying the link list, in that it is mentioned that link list is used instead of array

If you want to study linked lists, then you should also study when it's appropriate and advantageous to use them. A lookup table doesn't really fit the bill here.

"A lookup table doesn't really fit the bill here."

I think you meant "A linked list doesn't really fit the bill here."

For this specific case - translations of RPM into specific settings for a '51 chip - a sorted table is probably the best container type available, since it allows quick direct lookup in a minimum of memory.

apart from the obvious disadvantage of dynamic memory allocation, you might also want to consider the cost in terms of computation cycles: O(n) in the worst case for a linked list, unless some mostly useless tricks are used (that consume CPU cycles while maintaining them) like (I am not sure I am using the correct terminology here) "jump lists", that reduce average access time to O(log(n)).

"apart from the obvious disadvantage of dynamic memory allocation"

As already noted, it is perfectly possible to use linked-lists without any use of dynamic memory allocation!

The example I cited illustrates this.

Andy,
Where did I say otherwise? Of it is possible.

I meant, of course:
"of course it is possible."

With the '51 architecture, linked lists (dynamically allocated or not) are murder, whereas with e.g. the XA, they can be the best solution.
A list like you describe will, I assume be in XDATA, just make a linked list of 3 entries and look at the generated assembler then count the cycles to get to the 3rd entry. Then visualize the time to get to the umpteenth entry.

OK, it may be that you have all the time in the world, so to save the sardine from responding, if you want to totally ignore efficiency, go ahead and link your list.

Erik

"...if you want to totally ignore efficiency, go ahead and link your list."

'scuse me ... But I have used linked lists on an 8052.

You must learn to realise that efficiency is a relative term.

On the project in question, we considered acceptability of execution time at the project start, negotiated requirements with the customer and found, for the requirement that access to the list was considered acceptable when the list contained no more than 750 records.

If it is acceptable to the customer, then the code is sufficiently efficient.

Hint: Try taking off your blinkers - You might see a whole new world!

I think you meant "A linked list doesn't really fit the bill here."

Of course. Mistakes like that happen when I post before the first cup of coffee in the morning.

'scuse me ... But I have used linked lists on an 8052.

But did you use them for something that's most likely a static, ordered data structure ?

"But did you use them for something that's most likely a static, ordered data structure ?"

No, the data was dynamic, stored in a fixed area of memory (i.e., no use of malloc or the like), had records of variable length, written relatively infrequently and read relatively more frequently.

The point for us was that, when a search was needed, the required record was found in an acceptable time frame.