java chips useful for dylan? 
Author Message
 java chips useful for dylan?

Could Java chips (assuming they will actually be produced and used)
be in some way exploited by a Dylan compiler?

  Enrico



Sat, 08 May 1999 03:00:00 GMT  
 java chips useful for dylan?


  >Could Java chips (assuming they will actually be produced and used)
  >be in some way exploited by a Dylan compiler?

From my understanding of the Byte articles et al., the Java chip is
basically the Java Virtual Machine in silicon (which I suppose makes the
"virtual" part moot). Although others on this list are more qualified to
answer, I believe that the chip runs Java bytecodes. A Dylan implementation
that produced Java bytecodes could probably run those bytecodes on these
chips.

A multi-platform project that translates Ada 95 to Java bytecodes is
already in the beta stages < http://www.*-*-*.com/ ;, so it's my guess that
the same could be done for Dylan.

The question is...does anyone need this? Since many of Dylan's high level
features like multiple dispatch probably wouldn't translate well into Java,
it would seem to me that we're better served by general purpose RISC
processors (or X86 for nostalgia).


Los Angeles, CA         (213) 662-6308 | This message created and
  http://www.*-*-*.com/ ~athene    | sent via the {*filter*}dog Mail
   {*filter*} illustration & design     | System from Apple Computer
      eti kai nun Hellas phileo
IBM UNLEASHES THE 225 MHz PowerPC 604e--WORLD'S FASTEST DESKTOP CPU



Sun, 09 May 1999 03:00:00 GMT  
 java chips useful for dylan?



Quote:

>  >Could Java chips (assuming they will actually be produced and used)
>  >be in some way exploited by a Dylan compiler?

>From my understanding of the Byte articles et al., the Java chip is
>basically the Java Virtual Machine in silicon (which I suppose makes the
>"virtual" part moot).

  Correct the "Java Virtual Machine" should be more accurately named the
  "Java Machine Specification". :-)  There is no requirement that it
  be implemented in software. Only that it does the "correct" thing when
  presented the specified byte codes.

Quote:
>answer, I believe that the chip runs Java bytecodes. A Dylan implementation
>that produced Java bytecodes could probably run those bytecodes on these
>chips.

...
...

Quote:
>The question is...does anyone need this? Since many of Dylan's high level
>features like multiple dispatch probably wouldn't translate well into Java,

  Not mapping into Java isn't the problem. Not mapping into Java bytecodes
  would be a problem.

  I suppose this could be useful if used in conjunction with a
  Creole/Melange automagic binding of Java code from Dylan. This way one
  could freely intermix Java and Dylan ( at which point one could leverage
  off of all of the Java Libraries out there). But....

  The Dylan code could/would probably be decidedly larger than Java code
  [ Some common operations would require multiple bytecodes to
    implement such as the multimethod dispatch.] . Which if
  code is being distributed over the internet is a factor for some. If the
  code is embedded inside of a phone/toaster/"extremely thin client" this is
  a "show stopper".   [ My impression is that java chips are being aimed
  at this market. ]

  For constructs that mapped poorly there would be a significant speed hit.
  I'm not sure you could use the java object model since it doesn't handle
  multiple inheirtance ( it would be nice if slot access could at least
  use the java dispatch mechanism ( or slot accessing byte codes ). ).

  I'm still not convinced that the Java and Dylan models of exceptions
  can be made to work together.  For example could you restart from an
  exception thrown out of a "java" method?  Probably not. But where would
  restart go back to if one were defined........
  I'm also not sure you could make the "VM" do what you'd want it to do
  in order to get a restart to happen the way you want in Dylan anyway.
  If I'm not mistaken the VM does some of the execption work itself inside
  the "black box".
  [ So perhaps Dylan sans restarts may work.  I can't imagine that you
    can map the entirety of Ada95 into java byte codes though either. ;-) ]

Quote:
>it would seem to me that we're better served by general purpose RISC
>processors (or X86 for nostalgia).

 Rob MacLachlan has a paper "Lisp vs. RISC or What Common Lisp Implementors
 Really Want" http://www.cs.cmu.edu/afs/cs/user/ram/pub/arch.ps.

    "......In the MIPS CMU Common Lisp image, function call accounts for
     25% of the total code size.
           Even ignoring stack-addressed byte codes ( which may be 5x-10x
      more dense (13,6]), significant gains are possible from denser
      instruction coding. "

  Of course to offset this there is a fragment right before this where
  he states that the functional call on a Symbolics 3600 took approx 20
  cycles and in CMUCL it was 15 if no cache misses.  And if a Dylan
  compiler makes agressive use of the "superscalar/speculative" operations
  then RISC makes the classic space/speed tradeoff.... as long as the
  cache misses don't get too ridiculous.

  Is mapping onto the java VM worth it? I'm not so sure. If the motivation is
  to do it so that Dylan is seen "with the rich and famous/hyped" then
  probably not.  

  At one point I thought that it would be cool for a "mindy like" compiler to
  generate java byte code so that anybody could run programs created in
  Dylan. With a VM that had a JIT component you'd get compilation to native
  code "for free".   And if the "mindy like" compiler where written in Dylan
  then the compiler would be portable too... Hence a demo compiler that
  runs everywhere and generates code that runs everywhere....

  [ In no way does this solve the lack of "industrial strength" version(s)
    availability. But there are folks working on that "problem". :-)  ]

  However, the downside that folks will code some simple "benchmark" in
  Java and Dylan. Run both on the same VM and say "see Java is much
  smaller and faster...."  [ Which may be true even if both were compiled
  to a "neutral" target. However, the VM target may be even more lopsided. ]

  And debugging Dylan running on java VM might be not a lot of fun..
  ( Perhaps a different Debugging API would help here.)

--

Lyman S. Taylor           "Computers are too reliable to replace

                                Commander Nathan Spring, "Starcops"



Sun, 09 May 1999 03:00:00 GMT  
 java chips useful for dylan?

Quote:

> Could Java chips (assuming they will actually be produced and used)
> be in some way exploited by a Dylan compiler?

>   Enrico

My guess is somewhat, but it will not be a huge win.

According to the Byte article, the chip is mostly a stack-oriented
architecture.  This makes it very similar to Symbolics architectures
(3600, 3640, ivory), which would be helpful for Dylan.

But there is very little support for tagged architecture.  I believe
the Java chip has a one-bit tag for all objects, which is used for
marking objects for garbage collection.  While this can allow
multiprocess garbage collection (one process collects garbage
while other processes continue to run), it doesn't help at all
with dynamic typing, which is one of Dylan's (and Lisp's)
great strengths.

The writer of the article acutally did question the need for a
dedicated Java chip, citing the Lisp machine industry, which lost
out to general purpose chips (Sparc and 386s), based on runtime and
ease of delivery.

I think the Java chip will fail miserably.  Java's strength is its
multiplatform support.  Building a dedicated chip to run it will find
a very limited market.

DDL

--------------------
David Lowry
Dike Bronstein Roberts & Cushman LLP



Mon, 10 May 1999 03:00:00 GMT  
 java chips useful for dylan?

: The writer of the article acutally did question the need for a
: dedicated Java chip, citing the Lisp machine industry, which lost
: out to general purpose chips (Sparc and 386s), based on runtime and
: ease of delivery.

: I think the Java chip will fail miserably.  Java's strength is its
: multiplatform support.  Building a dedicated chip to run it will find
: a very limited market.

I imagine the market for $30,000 java-chip computers (like Lisp machines)
would be limited, but the market for $17 java-chip beepers might not be.

But why were Lisp machines unpopular?  COuld it just be that their
manufacturers didn't have the capital of Sun and Intel?

Of course, in 15 years, won't all processors be "java chips" just
as they are essentially "C chips" today?  And yet this Java chip computers
will be able to run C better than C chip computers can run java.

A "java chip" doesn't necessarily mean that the chip's hardware architecture
must directly map the Java virtual architecture.  In fact I imagine
such a thing to be sort of primitive animistic imitation---the JVM was
designed utterly without reference to fundamental physical hardware concerns.

A "java chip" is one which has been quantitatively and empirically designed
to quickly run java in a cost-effective way.

--

Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/



Tue, 11 May 1999 03:00:00 GMT  
 java chips useful for dylan?

Quote:

>I imagine the market for $30,000 java-chip computers (like Lisp machines)
>would be limited, but the market for $17 java-chip beepers might not be.

Very true - Java chips are likely to be aimed at the embedded market
(phones, toasters, TVs, etc...) which is, strangely enough, what Jave
was aimed at back when it was Oak.

Quote:
>A "java chip" doesn't necessarily mean that the chip's hardware architecture
>must directly map the Java virtual architecture.  In fact I imagine

According to Sun it does. Here's a direct quote from the picoJava I
white paper:

"To boost throughput, picoJava I directly executes the Java instruction
set, eliminating the need for an interpreter or JIT compiler (figure 1,
case 3). The processor is tailored to Java requirements, offering 100%
conformity with the Java Virtual Machine specification."

http://www.sun.com/sparc/whitepapers/wpr-0014-01/

The architecture is actually a very interesting hybrid - it implements a
stack-machine in hardware. The above quote is actually slightly
deceiving. It appears that the very core of the machine is a RISC-like
instruction set, with another layer (in hardware) that translates
byte-codes into this instruction set (although the Java stack model is
directly supported by the hardware).

Quote:
>A "java chip" is one which has been quantitatively and empirically designed
>to quickly run java in a cost-effective way.

Yep. I expect Sun to use different designs to acheive the same end. They
haven't said much about the UltraJava design, for instance. It seems
that won't be based on the picoJava core. Based on the white paper
however, the chips are very much geared towards Java, and fitting other
languages on top, like Dylan, might prove difficult.


Tue, 11 May 1999 03:00:00 GMT  
 java chips useful for dylan?


Quote:
>Of course, in 15 years, won't all processors be "java chips" just
>as they are essentially "C chips" today?

I wouldn't bet any large sum on that.  Remember the BBN "C machine"?


Tue, 11 May 1999 03:00:00 GMT  
 java chips useful for dylan?

Quote:

>Subject:    RE: java chips useful for dylan?


>>however, the chips are very much geared towards Java, and fitting other
>>languages on top, like Dylan, might prove difficult.

>It wouldn't be, with some very small tweaks.  In fact, Sun solicited input
>from several other languages when designing these chips.  I would not be
>surprised to see a number of OO languages eventually supported.

Cool! I'm glad to hear that - it gives me some small glimmer of hope
that Java won't be the next language monstrosity, like C++ is now. I'm
still praying for Dylan to take over the world, or at least climb to a
position where it's possible to deliver apps in.

And to think, it's all been done right before. Doomed to repeat.

-Adam

--

"C++ is arrogant and insulting - and in many cases simply
wishful thinking based on a limited field of knowledge."
             - Dissociated Bjarne



Tue, 11 May 1999 03:00:00 GMT  
 java chips useful for dylan?


Quote:
>The architecture is actually a very interesting hybrid - it implements a
>stack-machine in hardware. The above quote is actually slightly
>deceiving. It appears that the very core of the machine is a RISC-like
>instruction set, with another layer (in hardware) that translates
>byte-codes into this instruction set (although the Java stack model is
>directly supported by the hardware).

Amazing!  Just like Lisp chips.  In fact, Symbolics Open Genera is
essentially a software emulation of just that -- the Lisp emulator is a
pretty direct translation of the Lisp chip microcode onto an Alpha.

The only thing we can learn from history is that we are doomed to repeat it.

Quote:
>Yep. I expect Sun to use different designs to acheive the same end. They
>haven't said much about the UltraJava design, for instance. It seems
>that won't be based on the picoJava core. Based on the white paper
>however, the chips are very much geared towards Java, and fitting other
>languages on top, like Dylan, might prove difficult.

It wouldn't be, with some very small tweaks.  In fact, Sun solicited input
from several other languages when designing these chips.  I would not be
surprised to see a number of OO languages eventually supported.


Tue, 11 May 1999 03:00:00 GMT  
 java chips useful for dylan?

Quote:

>I imagine the market for $30,000 java-chip computers (like Lisp machines)
>would be limited, but the market for $17 java-chip beepers might not be.

>But why were Lisp machines unpopular?  COuld it just be that their
>manufacturers didn't have the capital of Sun and Intel?

My spin on the lisp market was that the lisp machines were great developement
environments, but there was no way to deliver final products.  A $30,000
delivery vehicle was impossible for most customer applications.

The other thing which killed (though it's not quite dead) the lisp machine
market was hardware memory prices.  Lisp just came too soon.  If companies
tried to market lisp machines today, with cheap RAM and very cheap storage
disks, the price would be much lower, and they could compete with stock
hardware.

Quote:
> Of course, in 15 years, won't all processors be "java chips" just
> as they are essentially "C chips" today?  And yet this Java chip computers
> will be able to run C better than C chip computers can run java.

Well, in 1980, CISC was the answer for processors.  Then RISC came along and
blew CISC off the map (slight exageration).  The trend definitely became to
produce screaming fast pipeline architecture, and leave expensive instructions
to software to implement.  Even Intel started to make the 486 and "586" more
risc-like.

What I really hope for in 15 years is basically "Dylan Chips", which I would
believe to be tagged risc.  Although it would have heavy stack support
features, it would still resemble a register machine.  It would have enough
tag bits to allow a wily compiler to assign tag identifiers to user-defined
objects in the class hierarchy.  Method dispatching would be dynamically
performed with no loss in throughput.

In any case, it's the usual deal of Lisp technology being reinvented ten
years later by the mainstream computer industry.  Oh well, it could be worse,
we could all be writing object oriented COBOL code now.

David Lowry



Tue, 11 May 1999 03:00:00 GMT  
 java chips useful for dylan?

Quote:

...

>My spin on the lisp market was that the lisp machines were great developement
>environments, but there was no way to deliver final products.  A $30,000
>delivery vehicle was impossible for most customer applications.

  As been mentioned before you could develop C, Ada on a Lisp machine also.

  Additionally, unless you utilized non Common Lisp features the results
  should have been quite portable onto  "cheaper" machines.

Quote:

>What I really hope for in 15 years is basically "Dylan Chips", which I would
>believe to be tagged risc.  Although it would have heavy stack support
>features, it would still resemble a register machine.  It would have enough
>tag bits to allow a wily compiler to assign tag identifiers to user-defined
>objects in the class hierarchy.  Method dispatching would be dynamically
>performed with no loss in throughput.

  Huh???  

  1. Tags for every user defined class isn't a good idea, if it could be
        implemented at all.
         When would the ID be assigned?
         What about "libraries"?
         What if the number of classes exceeds the number of bits devoted
          to tag usage?

     Note as you increase the number of bits you either decrease the size
        of the immediate values a word can store. Or have to increase the
        word size (more memory bits consumed that could be holding "data").

  2. I'm not so sure having "tag bits" will speed up method dispatch very much.
     Unless the object is register located the object's data will have to be
     fetched by a "load" anyway. The "load" that would retrieve the "tag"
     should often "prefetch" some (or most) of the object's data into
     whatever cache was around also. "You can pay me now or you can pay
     me later".

     User objects that can be allocated into registers ( and/or the stack)
     should have enough type info that the compiler can figure this out at
     compile time. Or if performance is of concerned such information should
     be given so that such analysis could be done.

--

Lyman S. Taylor           "I'm a Doctor, not a doorstop... "



Thu, 13 May 1999 03:00:00 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. Dylan and Java [was: Harlequin Dylan - Update]

2. Forth Chips as Java Chips; was Re: Design of future silicon to handle Java JVM

3. Java Chip Projects

4. FYI: chip-guru online chip design magazine

5. FYI: chip-guru online chip design magazine

6. Calling Java from Dylan

7. Dylan to Java/JVM compiler?

8. Dylan to Java?

9. (HD) Java Dylan interoperability

10. Dylan Java Source Code Comparison

11. More on Java vs Dylan

12. Java-to-Dylan

 

 
Powered by phpBB® Forum Software