|
[DPRG] embedded lua for robot computers
Subject: [DPRG] embedded lua for robot computers
From: Randy M. Dumse
rmd at newmicros.com
Date: Thu Apr 5 13:39:28 CDT 2007
Chris Jang wrote:
> Faster processors
> increase power requirements which impacts batteries, vehicle
> weight, size and thermal design. But storage is relatively
> cheap. It is practical to have many gigabytes of flash memory
> without significantly impacting power, weight or size. So
> design should favor space for time tradeoffs.
Efficiency is multifaceted. In a system that has 64K of memory,
how long does it take to read each cell? Versus a system with
8G, how long would it take to read that? Point being, if you
have lots of memory you don't have time to access, how is that
better than not having lots of memory. Or is it the same thing?
Having more memory may imply you must have a faster processor,
just to be able to read or write what you've got. Then all the
problems you list come into play, batteries, vehicle weight,
size and thermal design. And so on.
Programmers with long experience making little micros with small
memories do big things can probably tell you, they have very
different views of what efficiency is. A large memory by itself
generally does not mean efficiency.
There can be strong exceptions. For instance. If your large
memory were a math table, where it was indexed by operands, and
the solution was as easy as entering and operand as an address,
and extracting an answer from the memory, as opposed to doing
the long calculation with processing power, then, yes, that is
very efficient processor wise. (For example, you can keep a
16-bit transcendental function table (sin or cos) in 64K block
of memory, and get the answer in as little as a single indexed
load instruction without a floating point coprocessor.) But I
didn't get that was the sort of thing you were thinking of in
your post. Feel free to correct me if I misunderstood.
One of the surprizing concepts of Forth, I'll mention, since it
is becoming more of a lost art... Each call in Forth is just a
cell long (typically 2 bytes in a 64K map), as Forth programs
tend to get larger, they use less and less space to add more and
more features. Reason being is the pyramiding of code, with each
call of two bytes reusing some lower code function. By
comparison, a JSR in the same micro takes at least 3 bytes, one
for the op code, and two for the routines address. So you trade
threading inefficiency (overhead calling routines) for code size
efficiency (typically a savings of 30% and better than the
equivalent hand made machine code).
As I said, efficiency is multifaceted, and not easily
identified, without explaining what is the standard you are
measuring by.
Randy
www.newmicros.com
More information about the DPRG mailing list
|
