Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!ARIZONA.EDU!kwalker
From: kwalker@ARIZONA.EDU ("Kenneth Walker")
Newsgroups: comp.lang.icon
Subject: (none)
Message-ID: <8910120012.AA04649@megaron.arizona.edu>
Date: 12 Oct 89 00:12:51 GMT
References: <8910092321.AA23785@megaron.arizona.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 49

> Date: 9 October 89, 09:39:35 MEX
> From: Mario Camou R. (Dr. Mangagoras)                EM302723 at VMTECMEX
> 
> Hi,
> I have been browsing through the Icode files produced by ICONT. They seem to be
> coded in some kind of assembly code...Has anybody thought about writing some
> sort of an Icode assembler? It seems to me that a version of ICONX that worked
> with binary files should be faster than one that works with text files. Also,
> it SHOULD use less memory (maybe you UNIX hacks with gigabytes of virtual
> memory don't think much about this...but memory is scarce in the MS-DOS envi-
> ronment).

You can think of iconx as an intepreter implementing a virtual machine. In
which case the ucode (the text files produced with the -c option to icont)
can be viewed as a kind of assembly language. In addition to creating ucode
files, icont combines (links) them, resolving undeclared variables, and
produces icode files. The icode is in binary form and is the "machine code"
for iconx.

Even when you don't use the -c option, icont creates temporary ucode
files and deletes them when it is done. It would probably be more
efficient if icont created intermediate code in binary form rather
than as text. However, the text files are useful for debugging Icon and
for understanding the implementation. No one has yet done a lot of work
on improving the efficiency of icont.

It is possible to translate ucode into a real machine code. However, you
won't necessarily gain in terms of memory. Icode is quite compact. 
In addition, if you produce a real executable, you will have to link
in most of the Icon run-time system (the biggest part of iconx). Each
program you have compiled and linked will have a copy of this run-time
code, taking up a lot of disk space. If you think you can tell what is
called and thus link in only a fraction of the library, consider the
problem of string invocation (this is a problem we must tackle in our
research into an optimizing compiler for Icon).

Real machine code will gain you something in terms of speed, but
less than you might think. Icon programs spend most of their time
in run-time routines, not in intepreting icode instructions. An earlier
version of Icon had a compiler which produced machine code. In addition,
Janalee O'Bagy has a prototype compiler which produces machine code
(with C code as an intermediate step). The speed improvement for the
eariler compiler is usually quoted as being 5%-10% for typical programs.
In her dissertation, Janalee O'Bagy lists speed improvements for
naive compilation of 6 programs as ranging from 3% to 24%. Better
speed improvements require more than simple "assembly" of ucode.

   Ken Walker / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
   +1 602 621 2858  kwalker@Arizona.EDU   {uunet|allegra|noao}!arizona!kwalker