[Unicon-ldif] Unicon/Icon Translator in Unicon/Icon feedback questions.

[Bruce & B. R. <br...@dc...>]

Gentlemen and Ladies,

I am currently working on translating the icont c code to unicon/icon. I
have been thinking about the problem that this will create in terms of
getting an icont translator up and running on a newly installed system
without a c code version already in existence.

This has led me to having an icode file available that is the
translator. This in turn leads to the question of a standard format for
icode files across all systems running unicon/icon.

My questions for your consideration and feedback are:

What format should these files be in, big endian, little endian, etc?

What is your preferred format?

My own preference is big endian, but I'm not stuck on any particular
mode for the icode format.

Different systems have differing file systems, some record based, some
serial stream based. Should we have a version in all of these formats or
is that actually irrelevant in relation to the icon virtual machine? It
is many years (over 20 years) since I have had to deal with systems that
require record format file systems, so I am not up with what is
happening in that area at this time.

As an aside, I am looking at what modifications to the virtual machine
are required to create a indirect threaded virtual machine model with
fully standardise descriptors and structures, for the purposes of easily
extending the allowable base types within the virtual machine. These
investigations will be affected by the aforementioned questions. One of
the items that I would like to see is a facility to extend the runtime
system dynamically by loading in additional (shall we say) available
instructions. The prerequisite features are either creating new
instructions in c and dynamically linking them in or updating the
virtual machine by loading in indirect threaded code (ala FORTH and its ilk)

Some of the above items are described in the
http://unicon.org/helpwanted.html page. When it boils down to it, the
only area where c skills are needed are in the runtime, everything else
should be handled by expertise in unicon/icon. Even the iconc compiler
can be written in unicon/icon.

Some of this may be pie in the sky stuff but for all its faults, I like
programming in unicon/icon above most of the commonly available tools I
have had to use in my professional life and I want to have the areas
available extended. To think that all this stuff started because I
wanted to draw woodworking plans and was unhappy about the tools I have
available to me.

Any feedback will be appreciated.


regards to all

Bruce Rennie