Embedded Languages:
The discussion presented below is purely
specific to Embedded technology.
Criteria 1. Execution Speed
| Language |
On-line Interpreter |
Off-line Compiler +
On-line Interpreter |
Off-line Compiler |
| (E.g.) |
BASIC |
Java |
C |
Analogy:
You ask the
bearer for slices
of toasted
bread
Activity:
slice by slice
Process:
Eating toasted bread |
The bearer arranges a
toaster in front of you
with fresh loves of bread.
You will have to toast
each slice of bread with
the toaster and then eat.
|
The bearer arranges a
hot plate in front of you
with pre toasted bread.
You will have to heat
each slice of bread with
the hot plate and then
eat.
|
The bearer brings finely
toasted slices of hot
bread.
You just will have to eat
slices of bread.
|
| Compiler:
Interpreter:
Real Sense: |
none
Toaster
Here for every piece of
logic executed,
interpretation goes on-line
Here lot of time is
wasted by the interpreter |
Toaster
Hot plate
Here the logic is
converted into byte
code with an off-line
compiler,and then while
getting executed it goes
through the interpreter
(Virtual machine) on-line
Here again time is
wasted, but slightly
lesser |
Toaster
none
Here the logic is
converted into machine
code with an off-line
compiler and the code
straight a way runs on
the target machine
Here nothing is wasted |
Dependency:
correctness of |
Interpreter
Source code |
Interpreter
Source code |
Source code |
Which one for
Embedded? |
X |
X |
V |
Criteria 2. Flexibility
Embedded development calls for integrating
new devices with the development system . And in such cases it is required
to write new device drivers & virtual peripherals. Which involves work
at the machine core level (usually done in assembly level) manipulating
the HW resource. This in turn effects the balance between the HW &
SW resources pooled to bring in an effective device interface.
Using C, it is possible to write
code to respond & capture events at high speeds (Time precision) demanded
by the device interfaced with.
But imagine the case of BASIC &
Java, which does not allow HW to be accessed directly & it is only
possible through the interpreter services. This leads to latency in response.
And finally,
With C the developer writes program
over a High speed HW core (Real machine), but with Java it is over a slothful
SW interpreter (Virtual machine). surely the virtual machine is much slower
than the Real machine & lags the flexibility needed to write device
drivers.
Criteria 3. Portability
Portability is not a criteria that separates
Java from C. Any case both C & Java are portable across platforms.
Here again Java adds an initial problem of developing virtual machine for
the native Platform. Which is equal in complexity as to port the C HW
specific code across platforms.
Criteria 4. Reliability
This point alone complements Java for
the security offered, even though this is of least importance in the Embedded
scenario. The reliability is solely ensured by the interpreter, because
this is the only piece of code that is going to run in the machine. Where
as in C reliability lies in the hands of the developer, because every piece
of code is going to run directly in the machine.
This is the risk taken counting on
the advantages foreseen out of "C".
C shows sure possibility with
a risk, where as Java shows impossibility.
If you have
any point for or against the preceded discussion, please feel free to
email
me.
|
