Searching \ for 'Java?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=java
Search entire site for: 'Java?'.

Truncated match.
PICList Thread
'Java?'
1998\09\24@105428 by David Blain

picon face
part 0 117 bytes
Just thinking about possible future projects, and wanted to get a feel
for the number of people interested.

David.

1998\09\24@110250 by WF AUTOMACAO

flavicon
face
David Blain wrote:
>
> Does anyone know of, or would be interested in a Java Interpreter (VM)
> that would run on a pic with the p-code in a serial EEProm?
>
> Just thinking about possible future projects, and wanted to get a feel
> for the number of people interested.
>
> David.
>
>     ---------------------------------------------------------------

Humm, did you hear about Java Card?

M.

1998\09\24@112244 by David Blain

picon face
part 0 3501 bytes content-type:text/plain------ =_NextPart_001_01BDE7AC.78F00930
Content-Type: text/plain

No I have not!  Do you have any more info/Url?

David.

> {Original Message removed}

1998\09\24@112340 by , Norman F.

flavicon
picon face
In my opinion the pic and JAVA were made for each other.  The reduced
intruction set of JAVA was conceived and developed primarily so it could
reside using very little real estate.  So yes I for one see a great future
for JAVA and pic.
{Quote hidden}

1998\09\24@113443 by Nicholas Irias

flavicon
face
I like the idea of being able to run a high level language from EEPROM, but
I'm not sure I understand how java would offer a more universal environment
than a 'C' or BASIC interpreter.

Supposedly, the same java code runs in all VMs, and java is supposed to be
great for MCUs as well as larger computers.  But it seems to me that
virtually everything you want an MCU to do is specific to that MCU, so that
your java source for the PIC could not be loaded up on a Motorala MCU -
unless that java source code did not attempt to invoke any PIC-specific
capabilities.

At 10:45 AM 9/24/98 -0400, you wrote:
{Quote hidden}

1998\09\24@115125 by Claudio Rachiele IW0DZG

flavicon
face
part 0 588 bytes content-type:application/octet-stream; name=x                       Claudio Rachiele IW0DZG



PICLIST @ MITVMA.MIT.EDU
24/09/98 16:11
Please respond to PICLISTspamKILLspamMITVMA.MIT.EDU

To: PICLIST @ MITVMA.MIT.EDU
cc:
Subject: Java?

Does anyone know of, or would be interested in a Java Interpreter (VM)
that would run on a pic with the p-code in a serial EEProm?

Just thinking about possible future projects, and wanted to get a feel
for the number of people interested.

David.


- x
Content-Type: application/octet-stream; name=x
Content-Disposition: attachment; filename=x

Attachment converted: wonderland:x (????/----) (00017A29)

1998\09\24@120503 by Dan Larson

flavicon
face
On Tue, 18 Aug 1998 08:19:40 -0700, Nicholas Irias wrote:

>I like the idea of being able to run a high level language from EEPROM, but
>I'm not sure I understand how java would offer a more universal environment
>than a 'C' or BASIC interpreter.
>
>Supposedly, the same java code runs in all VMs, and java is supposed to be
>great for MCUs as well as larger computers.  But it seems to me that
>virtually everything you want an MCU to do is specific to that MCU, so that
>your java source for the PIC could not be loaded up on a Motorala MCU -
>unless that java source code did not attempt to invoke any PIC-specific
>capabilities.

Perhaps a more universal port twiddling interface could be made for Java,
that would port easily from one mcu to another,, but that would only work
for very common hardware.  Ports, A/D, Timers...  but not much else.  If that's
all you wanted, great.

If you didn't care about portable code and just want to use Java for its
own merits, then a PIC specifc library wouldn't do any harm.

One other concern is the potential high demand that an object oriented
interpreter would place on RAM.  The typical PIC probably does not
have enough. I never wrote a Java VM though, so I don't know for sure.
Serial RAM may be way too slow.

Just $.02 from a softare guy.....

Dan

1998\09\24@125351 by David Blain

picon face
part 0 12236 bytes content-type:text/plain------ =_NextPart_001_01BDE7B9.414244F0
Content-Type: text/plain

My initial thoughts would be to create a set of classes where each class
encapsulated specific functionality of the MPU in question.  The
interfaces for these classes would be well defined and only the
implementation would vary.

Some examples of classes would be (Just a quick thought):

     +-- class Interrupt
     |
     +-- class IOPort
     |    +-- class I2C
       |    |    +-- class EEProm
     |    |    +-- class RealTimeClock
     |    |
       |    +-- class UART
       |    |    +-- class SerialLCD
     |    |
       |    +-- class LCD (4/8 wire)
       |    +-- class IButton
     |
       +-- class Application
       |
       ...

Some of these classes would be implemented in the VM (Time critical) and
others could be implemented as p-code (Non-time critical) included with
the users program.

This would obviously mean that there would need to be a VM for each
type/family of processor.

Depending on the feedback I get, I would try to make it so that each
user could customize and build the features needed for any given project
into the VM.  (Not sure how to accomplish this without having to devote
all my time to tech support!)

As for the ram limitations... it is a problem.  The only way around it,
IMHO is to limit the use of real ram that the program can use, and offer
EEProm as a place to persist values that do not change/get used very
often.  I will have to think about this.

The first attempt at a VM would probably use SEEProm just because I know
how to use it.  I will just have to wait and see how bad the performance
is.  (Doesn't the Basic stamp use SEEProm?)

Any help in the design/implementation of the VM would be welcome!

David.



> {Original Message removed}

1998\09\24@132054 by Peter L. Peres

picon face
On Thu, 24 Sep 1998, Noplock, Norman F. wrote:

> In my opinion the pic and JAVA were made for each other.  The reduced
> intruction set of JAVA was conceived and developed primarily so it could
> reside using very little real estate.  So yes I for one see a great future
> for JAVA and pic.

You are mostly right imho, but unfortunately, Java VM's must implement so
many default objects to be able to run in the first place, that the VM's
size puts it outside the range of the PIC program memory. On top of that,
the Java VM implementations make extensive use of a stack and the PIC is
very short on that.

However, it should be possible to cross-compile Java bytecode into PIC
assembly assuming that the respective programs use a small subset of Java
so the resulting code does not exceed the PIC program store size.

This is a fairly complicated project, about on par with an optimizing C
cross-compiler implementation for the PIC. It can and probably will be
done, but I don't see the amateurs on the list doing it (me included) ;)
It's far more likely that the answer will come from the GNU corner or from
others who have already made optimizing C and Basic compilers (as opposed
to interpreters) for the PIC.

Last, I'd like to add that Java may not be a perfect choice for embedded
programming, at least not with the high level programming structures used
today (as opposed to bytecode hacking or its equivalent), for about the
same reason(s) that C++ is not very popular on small and tiny micros.

0.02 Agorot

Peter

1998\09\24@132307 by David Blain

flavicon
face
*** I don't think this made it to the list... If so, forgive the duplicate!
***

My initial thoughts would be to create a set of classes where  each class
encapsulated specific functionality of the MPU in question.  The
interfaces for these classes would be well defined and only the
implementation would vary.

Some examples of classes would be (Just a quick thought):

      +-- class Interrupt
      |
      +-- class IOPort
      |    +-- class I2C
      |    |    +-- class EEProm
      |    |    +-- class RealTimeClock
      |    |
      |    +-- class UART
      |    |    +-- class SerialLCD
      |    |
      |    +-- class LCD (4/8 wire)
      |    +-- class IButton
      |
      +-- class Application
      |
      ...

Some of these classes would be implemented in the VM (Time  critical) and
others could be implemented as p-code (Non-time critical) included with
the users program.

This would obviously mean that there would need to be a VM for each
type/family of processor.

Depending on the feedback I get, I would try to make it so that each
user could customize and build the features needed for any given project
into the VM.  (Not sure how to accomplish this without having to devote
all my time to tech support!)

As for the ram limitations... it is a problem.  The only way around it,
IMHO is to limit the use of real ram that the program can use, and offer
EEProm as a place to persist values that do not change/get used very
often.  I will have to think about this.

The first attempt at a VM would probably use SEEProm just because I know
how to use it.  I will just have to wait and see how bad the performance
is.  (Doesn't the Basic stamp use SEEProm?)

Any help in the design/implementation of the VM would be welcome!

David.

> {Original Message removed}

1998\09\24@134619 by John A. Craft

flavicon
face
No,  Java will eventually cause global destruction.  It is the root of all
evil and should be eliminated.

But I could be wrong.

Jc.

1998\09\24@145327 by David Blain

picon face
I seem to be having problems with my mail server... Forgive me if this is a
duplicate! :-(

---
My initial thoughts would be to create a set of classes where  each class
encapsulated specific functionality of the MPU in question.  The
interfaces for these classes would be well defined and only the
implementation would vary.

Some examples of classes would be (Just a quick thought):

      +-- class Interrupt
      |
      +-- class IOPort
      |    +-- class I2C
      |    |    +-- class EEProm
      |    |    +-- class RealTimeClock
      |    |
      |    +-- class UART
      |    |    +-- class SerialLCD
      |    |
      |    +-- class LCD (4/8 wire)
      |    +-- class IButton
      |
      +-- class Application
      |
      ...

Some of these classes would be implemented in the VM (Time  critical) and
others could be implemented as p-code (Non-time critical) included with
the users program.

This would obviously mean that there would need to be a VM for each
type/family of processor.

Depending on the feedback I get, I would try to make it so that each
user could customize and build the features needed for any given project
into the VM.  (Not sure how to accomplish this without having to devote
all my time to tech support!)

As for the ram limitations... it is a problem.  The only way around it,
IMHO is to limit the use of real ram that the program can use, and offer
EEProm as a place to persist values that do not change/get used very
often.  I will have to think about this.

The first attempt at a VM would probably use SEEProm just because I know
how to use it.  I will just have to wait and see how bad the performance
is.  (Doesn't the Basic stamp use SEEProm?)

Any help in the design/implementation of the VM would be welcome!

David.

1998\09\27@074716 by rank A. Vorstenbosch

flavicon
picon face
Noplock, Norman F. wrote:
>
> In my opinion the pic and JAVA were made for each other.  The reduced
> intruction set of JAVA was conceived and developed primarily so it could
> reside using very little real estate.  So yes I for one see a great future
> for JAVA and pic.

OK, let me see.  Typical Java byte code interpreters run to maybe 40KB, and
add anything between a 1KB and 1MB for the application code.  The use of
standard class libraries is going to make development a lot easier, but
just look at the size of these libraries...  I thing my JVM 1.16 has a few
MB of libraries.

The Java byte code isn't particularly space-efficient for something as
small as a PIC, and also has lots and lots and lots of things that you
don't need.  IHMO, things like the basic stamp is the logical way of doing
things (even though I wouldn't want to be seen dead trying to flog a basic
application to a client) -- lean interpreter, allowing for user token
extensions etc.  Dunno whether the basic stamp uses just tokenized basic
(silly) or something more like a stack-based system (proper).

Frank
------------------------------------------------------------------------
Frank A. Vorstenbosch    <SPAM_ACCEPT="NONE">   Mobile:  +44-976-430 569
Wimbledon, London SW19                          Home:   +44-181-544 1865
.....frankKILLspamspam.....falstaff.demon.co.uk                      Office: +44-181-636 3391

1998\09\27@091736 by paulb

flavicon
face
Frank A. Vorstenbosch wrote:

> IMHO, things like the basic stamp is the logical way of doing things
> -- lean interpreter, allowing for user token extensions etc.  Dunno
> whether the basic stamp uses just tokenized basic (silly) or something
> more like a stack-based system (proper).

 It«s Basic Jim, but not as we know it...

 Well, I don«t think it is really Basic at all, but it looks like Basic
before it is compiled into tokens.  It could just as easily be FORTH,
and I still have a dream of doing that ... but there is already a PIC
FORTH I«d have to study first.

 I used to think FORTH, being a multi-stack language, couldn«t be done
without a stack, but then the optimised or "assembled" versions keep at
least the top stack item in registers and can use direct or subroutine
threading instead of the classical direct.

 You think you simply *can«t* have much of a stack on a machine with a
three-cell hardware stack but once you are using token code, you are
"stacking" token pointers rather than machine instructions and for this
you can of course diddle the FSR register a lot.  Tokens or stacks is
not an "or" but an "and".

 What it really comes down to, is that there are very few ways of
performing the basic functions; looping, conditionals, subroutines on
such a sparse machine, so at the end of optimisation is is going to look
virtually the same.
--
 Cheers,
       Paul B.

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...