"Soc": Syntax-Oriented Coding 
Author Message
 "Soc": Syntax-Oriented Coding

I just ran across an article about "Syntax Oriented Coding" in Unix Open / Linux Open, a German computer magazine.  Their web site is www.linux-open.de, but the article isn't posted there yet.

At any rate, it describes a syntax-tree compression technique combined with modularization to greatly speed up the download of typical Java applications.  (Since the representation is far smaller than byte code and since modularization means fewer individual file requests.)

Sounds to me like someone picked up Michael Franz's Object Module Interchange (also used in the experimental Juice.)  And applied it to Java.  

There's no mention of this prior research in the article, however. A quote beneath a photo in the article reads:

``Photo of Eck, Xie and Matzner; the inventors of this new technology and founders of Syntion AG were awarded the Philip Morris Research Prize 2000 for their work.''

A missed opportunity for the Oberon-ites?

Further information at http://www.*-*-*.com/ , which covers the background and origins of the research.

-- ben



Mon, 31 Mar 2003 03:00:00 GMT  
 "Soc": Syntax-Oriented Coding


Quote:
> I just ran across an article about "Syntax Oriented Coding" in Unix
Open =
> / Linux Open, a German computer magazine.  Their web site is =
> www.linux-open.de, but the article isn't posted there yet.

> At any rate, it describes a syntax-tree compression technique
combined =
> with modularization to greatly speed up the download of typical Java =
> applications.  (Since the representation is far smaller than byte
code =
> and since modularization means fewer individual file requests.)

> Sounds to me like someone picked up Michael Franz's Object Module =
> Interchange (also used in the experimental Juice.)  And applied it to
=
> Java. =20

> There's no mention of this prior research in the article, however. A =
> quote beneath a photo in the article reads:

> ``Photo of Eck, Xie and Matzner; the inventors of this new technology
=
> and founders of Syntion AG were awarded the Philip Morris Research
Prize =
> 2000 for their work.''

> A missed opportunity for the Oberon-ites?

Very much so.  Slim binaries/Juice has been a series of missed
opportunities.  When it first came out it was MUCH faster than Java
because it translated to native code whereas Java was interpretted.
Java JIT technology pretty much caught up with Juice execution speed,
but that still left Juice with an edge in download speed.  Now that
might be in jepordy.  On the bright side there is research going on for
dynamic optimization in slim binaries which promises to surpass even
JIT "hotspot" technology.  Where Java has had a strong edge over Juice
(other than in just plain exposure) has been in the area of
development.  Although Juice was built using Oberon System 3 it did not
use the Gadgets GUI that came with it.  (This in contrast to "pluggable
Oberon" which uses Gadgets in a Netscape plug-in but not Slim
Binaries.)

This brings me to what is a general problem IMHO with current Oberon
development.  Each project stands alone.  The result is many similair
projects that each have "pieces" of what could be a good system by each
lack some essential element.  Take web-browsers for instance.  There
are web-browsers that have been independently developed for V4 and Sys
3.  Neither are really very good by modern standards.  There is an HTML
4.0 renderer for System 3, but it's not able to connect to the web.
Why is everything built independently of everything else?

Anyway, back to Juice and Slim Binaries.  There are a few things that
must happen if Juice is to ever become relevant.

1) The plugin must be ported to Linux.  Linux is one of the fastest
growing operating systems out there.  Today Linux support is as least
as important as MacIntosh support.

2) Integrate "LiveConnect" technology.  This would be a good stop-gap
measure for not having a decent GUI for Juice.  If Juice could
communicate better with the browser itself than the browser could serve
as the GUI for the applet.

3) Support more processors.  This is not as big of a deal today as it
used to be since DEC Alpha processors have never caught on and Sparc
stations seem to be loosing ground to Linux in accadamia.  But who
knows what else is on the horizon?  There needs to be a clear easy way
to port Slim Binaries to new processors when necessary.  That leads
right into my next point.

4) Better documentation of slim binaries.  I've been toying with Juice
for years and I still don't have a clue as to how it works behind the
scenes.  Maybe I've missed something in all of the papers I've read but
I can't find any clear documentation that says "here's how this thing
is actually put together."  Sure the source is available, but call me
slow.  I don't have the information that I would need to port Juice to
anything.  I would like something clear like the Java VM
documentation.  I realize that the Java VM might be easier to document
since it's a stack oriented VM as opposed to a DAG, but there's got to
be some way to systematically document this thing.

5) XML support.  I'm not just thinking about making Juice "buzzword
compliant".  There are some cool XML specs coming out these days
including SMIL (the XML multimedia language) and SVG (the XML vector
graphics language).  While you might not get a user interested in
downloading Juice to look at your "sishiphus" applet, you might get a
lot of downloads of a decent Juice-based SMIL or SVG plugin.

6) Capability based security.  This is a broad topic, but think of it
as "end-user defined sandboxing".  For real information on the subject
see :

http://www.eros-os.org/
http://www.erights.org/

7) Perhaps this is the most important, some "way cool" applets written
by the Oberon community!  When you think about it, most "flash" applets
aren't that technically challenging, but they look cool.  Juice needs
to be extended to be able to do simple "flash like" animations.
Perhaps supporting SMIL is the way to go about this.

Finally I would like to see some type of co-operation between
the "pluggable Oberon" folks and the "Juice" folks.  Even if the only
level of co-operation was in the area of building and maintaing a
plugin building API that could be used by both groups.

Quote:
> Further information at http://www.syntion.de/HTML/geschichte.html , =
> which covers the background and origins of the research.

> -- ben

--
Guns don't kill people...bullets do.

Sent via Deja.com http://www.deja.com/
Before you buy.



Sun, 06 Apr 2003 03:00:00 GMT  
 "Soc": Syntax-Oriented Coding

Quote:
> 4) Better documentation of slim binaries.  I've been toying with Juice
> for years and I still don't have a clue as to how it works behind the
> scenes.  Maybe I've missed something in all of the papers I've read but
> I can't find any clear documentation that says "here's how this thing
> is actually put together."  Sure the source is available, but call me
> slow.  I don't have the information that I would need to port Juice to
> anything.  I would like something clear like the Java VM
> documentation.  I realize that the Java VM might be easier to document
> since it's a stack oriented VM as opposed to a DAG, but there's got to
> be some way to systematically document this thing.

i think this should be the first and most important step. if one doesn't
know how to code/decode slim binaries, no-one be able to work with it.
is there a precise documentation out there that i missed?

cheers
pedro



Mon, 07 Apr 2003 03:00:00 GMT  
 "Soc": Syntax-Oriented Coding


Quote:

> > 4) Better documentation of slim binaries.  I've been toying with
Juice
> > for years and I still don't have a clue as to how it works behind
the
> > scenes.  Maybe I've missed something in all of the papers I've read
but
> > I can't find any clear documentation that says "here's how this
thing
> > is actually put together."  Sure the source is available, but call
me
> > slow.  I don't have the information that I would need to port Juice
to
> > anything.  I would like something clear like the Java VM
> > documentation.  I realize that the Java VM might be easier to
document
> > since it's a stack oriented VM as opposed to a DAG, but there's got
to
> > be some way to systematically document this thing.

> i think this should be the first and most important step. if one
doesn't
> know how to code/decode slim binaries, no-one be able to work with it.
> is there a precise documentation out there that i missed?

> cheers
> pedro

While I agree with you that documentation is important, I strongly
disagree with your assertion that no one can work with slim binaries
unless they know how to code/decode them at a low level.  Think of how
many Java programmers are out there who don't have a clue of how the
Java VM works.  Think of how many Linux/C programmers do not understand
the intricacies of the a.out or elf formats.  The only reason you need
to know how Slim Binaries system works at the low level is if you are
considering porting it to a new platform.  Currently its on x86, 68K
and PPC processors under Windows and Mac.  Porting to Linux would (to
me) be the next logical step.  I think porting to Linux x86 would be
possible without knowing the low level.  (Actually Slim Binaries
already works under Linux.  It's just the Juice plug-in itself that
doesn't work).

For the record there is Michael Franz' dissertation available.  It's
pretty good at describing semantic dictionary encoding (the algorithm
behind slim binaries) at a high level.  What I'd like to see would be
more of a case study.  "Here's processor X.  It has these op-codes and
these registers.  To write a decoder for processor X you need to do
blah and blah."  But from what I gather from someone working on the
advanced slim binary project the low level specs are currently being
overhauled anyway, so any new documenation might be soon out of date.
The current best low-level docs I know about are at :

http://www.inf.ethz.ch/publications/diss.html
(See Michael Franz dissertation)

http://www.ics.uci.edu/~franz/
(Especially see Adaptive Compression of Syntax Trees and Iterative
Dynamic Code Optimization: Two Basic Technologies for Mobile-Object
Systems)

Still porting Juice to other processors is not the most pressing issue
IMHO.  Windows, Linux and Mac are currently by far the most widely used
platforms.  Being able to port to other processors would be a must if
someone was considering running Juice on a Windows CE device since many
of the use the MIPs chip.  But just cleaning up and improving the API
and then actually BUILDING interesting apps on top of it are the most
important things to do.

--
Guns don't kill people...bullets do.

Sent via Deja.com http://www.deja.com/
Before you buy.



Mon, 07 Apr 2003 03:00:00 GMT  
 "Soc": Syntax-Oriented Coding

Quote:
> While I agree with you that documentation is important, I strongly
> disagree with your assertion that no one can work with slim binaries
> unless they know how to code/decode them at a low level.  Think of how
> many Java programmers are out there who don't have a clue of how the
> Java VM works.  Think of how many Linux/C programmers do not understand
> the intricacies of the a.out or elf formats.  The only reason you need
> to know how Slim Binaries system works at the low level is if you are
> considering porting it to a new platform.  Currently its on x86, 68K
> and PPC processors under Windows and Mac.  Porting to Linux would (to
> me) be the next logical step.  I think porting to Linux x86 would be
> possible without knowing the low level.  (Actually Slim Binaries
> already works under Linux.  It's just the Juice plug-in itself that
> doesn't work).

the reason people can work with java bytecodes and a.out files is that
there are readily available virtual machines and a.out loaders. what i
wanted to do was to implement a small loader/interperter with a small
api for posix-systems (basic i/o and networking, maybe even basic
windowing).

Quote:
> For the record there is Michael Franz' dissertation available.  It's
> pretty good at describing semantic dictionary encoding (the algorithm
> behind slim binaries) at a high level.  What I'd like to see would be
> more of a case study.  "Here's processor X.  It has these op-codes and
> these registers.  To write a decoder for processor X you need to do
> blah and blah."  But from what I gather from someone working on the
> advanced slim binary project the low level specs are currently being
> overhauled anyway, so any new documenation might be soon out of date.
> The current best low-level docs I know about are at :
> http://www.inf.ethz.ch/publications/diss.html
> (See Michael Franz dissertation)

> http://www.ics.uci.edu/~franz/
> (Especially see Adaptive Compression of Syntax Trees and Iterative
> Dynamic Code Optimization: Two Basic Technologies for Mobile-Object
> Systems)

i got the docs and will deffinitely read them.

Quote:
> Still porting Juice to other processors is not the most pressing issue
> IMHO.  Windows, Linux and Mac are currently by far the most widely used
> platforms.  Being able to port to other processors would be a must if
> someone was considering running Juice on a Windows CE device since many
> of the use the MIPs chip.  But just cleaning up and improving the API
> and then actually BUILDING interesting apps on top of it are the most
> important things to do.

it would be interesting to have a generic slim binary compiler with a
pluggable back-end (although the whole thing is pretty much a back-end).
probably just a parser for slim binary to parse-tree...

cheers
pedro



Tue, 08 Apr 2003 03:00:00 GMT  
 "Soc": Syntax-Oriented Coding


Quote:
> the reason people can work with java bytecodes and a.out files is that
> there are readily available virtual machines and a.out loaders. what i
> wanted to do was to implement a small loader/interperter with a small
> api for posix-systems (basic i/o and networking, maybe even basic
> windowing).

Some years ago someone implemented a Juice compiler under Oberon/F (now
component Pascal) called Gazelle.  It was going to be a commercial
product and it looked promising.  I even downloaded and played with it
a bit.  Unfortunately Gazelle just "vanished" into thin air.  I lost
the download I had in a hard disk crash.  :-(  (And of course the
download didn't have the source code anyway.)

Anyway your idea sounds interesting.  Are you looking at a particular
processor/operating system?  One good thing about the Juice design is
that it's not very dependent upon System 3 so porting it shouldn't be
too hard.  Actually I'd love to help with a Juice project because in
the end I think that's the only way I'll ever learn how it really works.

Quote:
> > For the record there is Michael Franz' dissertation available.  It's
> > pretty good at describing semantic dictionary encoding (the
algorithm
> > behind slim binaries) at a high level.  What I'd like to see would
be
> > more of a case study.  "Here's processor X.  It has these op-codes
and
> > these registers.  To write a decoder for processor X you need to do
> > blah and blah."  But from what I gather from someone working on the
> > advanced slim binary project the low level specs are currently being
> > overhauled anyway, so any new documenation might be soon out of
date.
> > The current best low-level docs I know about are at :
> > http://www.inf.ethz.ch/publications/diss.html
> > (See Michael Franz dissertation)

> > http://www.ics.uci.edu/~franz/
> > (Especially see Adaptive Compression of Syntax Trees and Iterative
> > Dynamic Code Optimization: Two Basic Technologies for Mobile-Object
> > Systems)

> i got the docs and will deffinitely read them.

> > Still porting Juice to other processors is not the most pressing
issue
> > IMHO.  Windows, Linux and Mac are currently by far the most widely
used
> > platforms.  Being able to port to other processors would be a must
if
> > someone was considering running Juice on a Windows CE device since
many
> > of the use the MIPs chip.  But just cleaning up and improving the
API
> > and then actually BUILDING interesting apps on top of it are the
most
> > important things to do.

> it would be interesting to have a generic slim binary compiler with a
> pluggable back-end (although the whole thing is pretty much a back-
end).
> probably just a parser for slim binary to parse-tree...

> cheers
> pedro

Agreed.  What would be nice would be a type of "expert system" where
you could describe the processor and let the computer design the
correct back end for it.  For example, if you could say "Processor X
has 2 address registers, 5 general purpose registers a 32 bit address
path, ect.  Floating point instructions are blah."  I suppose this
might cut down on effiency of the final compiler, but it would help in
porting the back-end quickly.  Optimization could always come later.

--
Guns don't kill people...bullets do.

Sent via Deja.com http://www.deja.com/
Before you buy.



Tue, 08 Apr 2003 03:00:00 GMT  
 "Soc": Syntax-Oriented Coding

Quote:
> Anyway your idea sounds interesting.  Are you looking at a particular
> processor/operating system?  One good thing about the Juice design is
> that it's not very dependent upon System 3 so porting it shouldn't be
> too hard.  Actually I'd love to help with a Juice project because in
> the end I think that's the only way I'll ever learn how it really works.

for now i'm hitting for an interpreter. it's not that fast (at all), but
it's just to see if i can do it. the non-dependency on system 3 (or now
eth oberon) is both a blessing and a curse for the same reason: no
standard library. In and Out should be easy. NetSystem a bit harder.
some form of windowing -- well, this is _very_ long term. to get to the
point: what will be more interesting than the compiler/interpreter are
the libraries you supply (i.e. the virtual machine system calls). it's
only once you have these that programmers will actualy be interested.

i can imagine that a form of oberon/slim-binaries could be interesting
for education: small apps (basic in/out) that run pretty much _anywhere_
(very important if you ever had to correct them) from a terminal.

Quote:
> Agreed.  What would be nice would be a type of "expert system" where
> you could describe the processor and let the computer design the
> correct back end for it.  For example, if you could say "Processor X
> has 2 address registers, 5 general purpose registers a 32 bit address
> path, ect.  Floating point instructions are blah."  I suppose this
> might cut down on effiency of the final compiler, but it would help in
> porting the back-end quickly.  Optimization could always come later.

at the moment i'm working on a oberon2 compiler for strong arm. although
it may take a while to get there (i'm still a student). the idea -- for
portability -- is to allow (better: assume) only a few basic
instructions (mov, add, mul, ldw, stw, etc...) that all processors have
and translate to the target machine as a last step.

i'm assuming general purpose registers (no x86-crap). the back-end can
then supply the instructions, nr. of instructions per tick, execution
lenght of each instruction (scheduling), existence or not of conditional
instructions, information on the size of pointers and basic types, the
existence or not of an fpu, stack growth direction and prologue/epilogue
of procedure calls. it's a far cry from a processor "description", but
making a back-end should be easier.

as i am a _not_ a compiler expert (by far), it could be that i'm trying
something completely delusional. if anybody sees some basic flaw in my
reasoning, please tell me!

cheers
pedro



Tue, 08 Apr 2003 03:00:00 GMT  
 "Soc": Syntax-Oriented Coding
Hallo!

Quote:
>for now i'm hitting for an interpreter. it's not that fast (at all), but
>it's just to see if i can do it. the non-dependency on system 3 (or now
>eth oberon) is both a blessing and a curse for the same reason: no
>standard library. In and Out should be easy. NetSystem a bit harder.
>some form of windowing -- well, this is _very_ long term. to get to the
>point: what will be more interesting than the compiler/interpreter are
>the libraries you supply (i.e. the virtual machine system calls). it's
>only once you have these that programmers will actualy be interested.

The ooc compiler is Oberon System independed and offers a standard
library for a lot of things. There excists also a GUI system working on
top of X11 (and once proven to also work on Windows) based on the
compiler and its library. The standard library is based on Posix and is
mostly Oberon-2 together with a little bit C for low level access. Both
libraries are under LGPL. It would be far better to reuse them than to
to everything on your own.

ooc also is a compleed C generating compiler. For all people interested
in modern compiler technology it is IMHO far more interesting in
participating to that compiler than restarting all over again.
The compiler is exspecially in need of native backends. If a slim binary
backend can be written was once dsicussed but could AFAIK not
be answered completely because of the lack of information about Juice.
If interested I would suggest to contact the authors for more
information.

--
Gru?...
       Tim.



Wed, 09 Apr 2003 03:00:00 GMT  
 "Soc": Syntax-Oriented Coding

Quote:
> at the moment i'm working on a oberon2 compiler for strong arm. although
> it may take a while to get there (i'm still a student). the idea -- for
> portability -- is to allow (better: assume) only a few basic
> instructions (mov, add, mul, ldw, stw, etc...) that all processors have
> and translate to the target machine as a last step.

Have a look at Paul Reed's paper in the JMLC'2000 proceedings.  He retargeted
Wirth's Oberon compiler using a similar technique.

-- Pieter

--
Pieter Muller, Institute for Computer Systems, ETH Zurich
Native Oberon OS: http://www.oberon.ethz.ch/native/



Fri, 11 Apr 2003 15:03:32 GMT  
 "Soc": Syntax-Oriented Coding

Quote:

> Hallo!
> The ooc compiler is Oberon System independed and offers a standard
> library for a lot of things. There excists also a GUI system working
on
> top of X11 (and once proven to also work on Windows) based on the
> compiler and its library. The standard library is based on Posix and
is
> mostly Oberon-2 together with a little bit C for low level access.
Both
> libraries are under LGPL. It would be far better to reuse them than to
> to everything on your own.

> ooc also is a compleed C generating compiler. For all people
interested
> in modern compiler technology it is IMHO far more interesting in
> participating to that compiler than restarting all over again.
> The compiler is exspecially in need of native backends. If a slim
binary
> backend can be written was once dsicussed but could AFAIK not
> be answered completely because of the lack of information about Juice.
> If interested I would suggest to contact the authors for more
> information.

> --
> Gru?...
>        Tim.

I've never understood this sense of competitiveness from the OOC
crowd.  Some people like working on the OOC project, fine.  Others are
interested in other pursuits.

--
Guns don't kill people...bullets do.

Sent via Deja.com http://www.deja.com/
Before you buy.



Fri, 11 Apr 2003 03:00:00 GMT  
 "Soc": Syntax-Oriented Coding

hello!

Quote:
> The ooc compiler is Oberon System independed and offers a standard
> library for a lot of things. There excists also a GUI system working on
> top of X11 (and once proven to also work on Windows) based on the
> compiler and its library. The standard library is based on Posix and is
> mostly Oberon-2 together with a little bit C for low level access. Both
> libraries are under LGPL. It would be far better to reuse them than to
> to everything on your own.

if i can get an interpreter working, porting any module that does not
directly depend on the system3 environment should be feasible (probably
misspelled that...). as for visual oberon and the standard ooc-library,
the problem lies in the little bit of c. if it's all system calls, then
they can be replaced by something like SYSTEM.syscall(whatever). for
library calls, i rather make a oberon wrapper for them.

i've been having a look at the library and it seems that most modules
are already available to system3. as for file handling, i guess that
porting the rider-system to posix shouldn't be much of a hassle (just
port ofs).

Quote:
> ooc also is a compleed C generating compiler. For all people interested
> in modern compiler technology it is IMHO far more interesting in
> participating to that compiler than restarting all over again.
> The compiler is exspecially in need of native backends. If a slim binary
> backend can be written was once dsicussed but could AFAIK not
> be answered completely because of the lack of information about Juice.
> If interested I would suggest to contact the authors for more
> information.

well, since the slim binary interpreter is a back end, the ooc front-end
doesn't help much. the reason i'm writing my own compiler is pretty much
just for the hell of it.

if you want a native backend for ooc, then you're going to have to be
carefull with the use of c in your libraries.

cheers
pedro



Fri, 11 Apr 2003 03:00:00 GMT  
 "Soc": Syntax-Oriented Coding

Quote:



> > Hallo!
> > The ooc compiler is Oberon System independed and offers a standard
> > library for a lot of things. There excists also a GUI system working
> > on top of X11 (and once proven to also work on Windows) based on the
> > compiler and its library. The standard library is based on Posix and
> > is mostly Oberon-2 together with a little bit C for low level access.
> > Both libraries are under LGPL. It would be far better to reuse them
> > than to to everything on your own.

> > ooc also is a compleed C generating compiler. For all people
> interested
> > in modern compiler technology it is IMHO far more interesting in
> > participating to that compiler than restarting all over again.
> ...[snip]..
> I've never understood this sense of competitiveness from the OOC
> crowd.  Some people like working on the OOC project, fine.  Others are
> interested in other pursuits.
> --

 Hopefully oberoners are CO-OPERATING, while competing against time.
 Encouraging join-and-cooperate is like is like advising the next
 generation to not start smoking: good advice, but seldom taken.

 System 3 has been of great value to me, and I appreciate those
 who previously joined-and-cooperated to make it possible.
 However, as is always the case, as size and complexity increase,
 serious diminishing returns set in.  The value added by new cool-stuff
 is swamped by the lack of management of the old stuff (eg. many
 existing utilities lacking doc/Tool).

 I'd like URL(s) to see how/if ooc handles these problem.



Sat, 12 Apr 2003 03:00:00 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

2. Visual Basic to go "Object Oriented"

3. "Object-Oriented Software Construction", 2nd edition

4. "Object-Oriented Applications": publication announcement (long)

5. more on [matz:"Human Oriented Programming"?]

6. "byte oriented platforms"? (was python compiler)

7. "Object-Oriented Applications": publication announcement (long)

8. syntax error - unexpected token "OFFSIDE"

9. "Lisp" syntax differences

10. new, "improved" syntax

11. Rare Syntax error on time "R"

12. Syntax "surprise"

 

 
Powered by phpBB® Forum Software