let's talk

[Emmanuel Marty]

Hi !

> Say, why aren't we using this mailing list?  There's all kinds of low-level
> work going on... Retro, Clementine, Forth & Scheme interpreters, persistent
> storage... We should be using this list to coordinate our efforts.

That's completely true. We should discuss our projects much more,
retro and clementine are healthy, friendly and beneficial competition
into which Tunes will probably find good ideas and ditch the bad ones.

> I looked at the LLL subproject page today... it's almost done already!  The
> goal was basically to implement a portable low-level language (i.e., a
> variant of Forth), a portable object format (XCOM fills that demand),
> persistent storage, and a minimal OS to support this stuff (Retro,
> Clementine, etc).  All we gotta do is finish these things up and get started
> on the high-level stuff.

The current version of XCOM headers, docs and tools is here now:
http://www.tunes.org/~core/xcom.tar.gz

Includes updated documentation (in sync again) and patches to
gdb 4.18 and nasm 0.98p6 (this one contributed by Fare).

You can use XCOM freely; I'll be pleased if it becomes the interchange
format between the various projects and it seems to go this way. Changes
and suggestion to the format before it is frozen in stone for public
consumption is also welcome.

David: I would like to setup a mailing list to discuss further XCOM
development, there probably won't be many people on it, but at least
Tom Novelli (for Retro) and Samuel L. Falvo II (for Dolphin) want to
use it; Samuel contributed useful ideas and is writing a linker for
xcom with full functionality (multi-architecture, etc.).

Do you mind if we use tunes-lll in the meantime?

In the near future I would also like to have http://xcom.tunes.org,
hosted on Bespin, mapped to a subdirectory of my account (or another
account, it's all good) for all relevant description of XCOM, and
also a cvs repository for the relevant files, and patches to the
various tools, until they are included in the mainstream distributions
(whenever I send them to their maintainers I guess :). Could you
create them whenever you have time? I'll populate them as soon as
it's done.. If you want to :) If this is a problem I'll set them
up on my servers, but since this is relevant to the tunes project,
I'd rather keep all in one place...

Tom, Sam: I want to change two things in XCOM. 1) the architecture
description string is useless. It's not used by anything important
right now, so I'd like to discuss an useful way. 2) the
interface section, I would like to find a way to make it so that
the linker can do fixup inside it, and still not have to know
the format used by the OS it is destined to. That should
be relatively simple, as only Clementine has interfaces right
now, and I can break them as much as I like.

XCOM doesn't support position-independent code right now but
it will sometime soon.

For the format, are there any people up to the relatively simple
tasks of :

* SGML'ing the documentation

* Fixing errors in spelling and grammar, in the documentation,
  headers and patches. I'm French, and there could be a
  lot of them. Someone please have a look.

* Writing an XCOM loader as an usermode program for POSIX OS'es.
  That could greatly simplify testing; xcom makes it very
  easy to have that program 'export' the functionality
  expected by currently in-development OSes such as Retro
  or Clementine. Writing application components would be 
  a breeze as they could be tested under the 'virtual
  environment' before they are executed stand-alone.

* Writing an XCOM loader for the Linux kernel, as a 'misc
  loader' module? That shouldn't be too hard, and should
  nicely insert as a module with no need to patch the
  base kernel.. This would also probably require designing a
  small 'INTERFACE' section for it.

* Trying to figure out why gdb won't point to the correct
  source line numbers when debugging an xcom object, although
  everything else (symbols, addresses..) is correct.

* Making Debian packages of the patched tools (binutils,
  gdb, nasm). This should be relatively trivial: getting
  the source package, applying the patch, using the provided
  Debian tools to build it as a binary package. This is
  however time-consuming. Anyone with some debian packaging
  knowledge up to it?

Help would be greatly appreciated ...

> Things going on at the moment:
> 
> * Clementine - Last I heard, Emmanuel Marty was getting ready to release his
> OS under the GPL... once his company OKs it.

That's correct. That, and polishing a few things so I don't have to
wear a brown paper bag (c), but company is what is holding it back.
Soon..

The XCOM parts aren't vetoed right now though (since 75% of it is
patches to gnu tools..), so at least this can get out right now and
be useful to Retro, Tunes, Dolphin ...

> * Retro - I have more time for it, now that I'm done with college (I still
> have to make a living though).  I just overhauled the web page yesterday:
> http://bespin.tunes.org/~tcn/retro.html

Excellent. How is the XCOM loader? Any trouble?

> * Hardware docs - we're putting everything we can get hold of on
> bespin.tunes.org.  Stay tuned to this list for further notice..

I have put a few links on the OS review, but there are many more
I'm sure. Especially rarities like correct FDC documentation.. Maybe
we should make an "hardware review"? :)

--
Emmanuel