Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!ARIZONA.EDU!kwalker
From: kwalker@ARIZONA.EDU ("Kenneth Walker")
Newsgroups: comp.lang.icon
Subject: Re: Why ICON?
Message-ID: <8909111711.AA09803@megaron.arizona.edu>
Date: 11 Sep 89 17:11:13 GMT
References: <7174@rpi.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 49

> Date: 10 Sep 89 15:26:23 GMT
> From: gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!vicc@tut.cis.ohio-state.edu  (VICC Project (Rose))
> 
> On the subject of portability I have a few questions:
> 
>    are executable images (.ICX) portable to all machines?

Without investigating too thoroughly, I believe there are a number of
problems preventing an i-code file from being executed by the iconx
intepreters on differenct machines. Numeric constants are stored in
the files in binary form. Thus differnt byte ordering within integers
will cause problems as will different floating point formats. There
may also be problems with different data sizes between some systems.
I-code files on Unix systems have an executable header which finds
and invokes iconx. This header prevents these i-code files from
being used on systems without them or on systems with different sized
headers. There may be other portability problems, though none come to
mind at the moment.

>    how about some way to allow a standard call to included assembly language
>    routines (or .OBJ type files from compilers)? Is this what personalized
>    interpreters allow? If so could this feature be ported to the micro domain?

The assmebly language (or C or Pascal or ...) routine must be called from
iconx. This means that either you need a dynamic linking facility or you
must relink iconx to specifically include the routine. In addition, any time
you do ``mixed language programming'', you may have to translate data from
the internal format of one language to that of the other. Iconx is written
in C. Becuase values in Icon include type information, even simple Icon types
do not map into primative C types; structures must be used. The present
method for adding a new function to Icon is to write a C routine which
manipulates the structures used to implement Icon types and to tell
icont/iconx about the new routine. On most systems, these C routines may
call routines in written other languages. The personalized interpreter
system just provides a way to compile and link a modified iconx without
making a copy of the entire source. If you want the source for several
modifications of Icon on one system, it will save you disk space, but
does nothing else.

>    how about a standard of some sort for system calls with some standardization
>    for particular calls such as something like -
> 
>        syscall("movecursor",x,y)

This sort of thing would certainly be useful, though it probably won't
get done by the Icon Project.

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