Language for ubiquitous computing

kallol borah <kallol.borah@gmail.com>
31 Aug 2005 00:35:01 -0400

          From comp.compilers

Related articles
Language for ubiquitous computing kallol.borah@gmail.com (kallol borah) (2005-08-31)
Re: Language for ubiquitous computing DeltaOne@mail2scientist.com (DeltaOne) (2005-09-07)
| List of all articles for this month |
From: kallol borah <kallol.borah@gmail.com>
Newsgroups: comp.compilers
Date: 31 Aug 2005 00:35:01 -0400
Organization: Compilers Central
Keywords: design, question
Posted-Date: 31 Aug 2005 00:35:01 EDT

Hi
I am writing to know your views on a language that can support
concurrent and distributed computing across any device/host, be it a
8/16/32 bit embedded platform or a high end PC/Server platform. A lot
of applications for sensor networks, vehicular networks, defense
command/control, networked consumer devices, etc depend on the ability
for diverse h/w platforms and s/w on it to cooperatively execute tasks
- however, most languages we have today do not support abstractions
for cooperative execution (coordination abstractions) or tightly
integrate services (often put under the category 'middleware') like
transaction mgmt or fault tolerant communications or routing to the
language run time.


We have actually implemented a language called Indus - a general
purpose, object oriented programming language - but with a focus on
concurrent and distributed executing of tasks across various h/w
platforms. Indus now compiles to Java (there is almost a 1:2 in terms
of how much java code gets generated) and we are now working on
bytecode to C compilation so that an Indus 'agent' can be cross
compiled using GCC and deployed on anything from a 8 bit
microcontroller onwards. Of course, we had to re-implement the Indus
run time (a set of libraries called a container) - in cases where the
run time executes on a JVM, it does self-configuration, discovery, f/t
connections, routing, tx management, policies, etc and in cases where
the run time has to execute on a OS/OS-less platform, it also does
thread mgmt, synchronisation, etc.


We also need some advice on the bytecode to C compilation - especially
wrt de-virtualisation, stack allocation of memory, code factorisation
(if any, is desirable) and any other technique to improve on footprint
/ performance.


Regards
Kallol


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.