[FreeVMS] Status Update ...?

[BERTRAND Joel]

anthony c wrote:
>  > I know; I only think that, in a first time, we have to write a stable 
> kernel on only _one_ arch. In a second time, we can add some archs.
> 
> That's the plan: a portable kernel (i.e. portable C, easy assembly 
> migration), written for x86 first then ported to whatever other 
> architecture we want/need later in the process.

	Yes, written in C but with several limitations (for examples, all 
string routines use string descriptor, not C pointers).

>  > If this is only a 64-bit interface, will it still be possible to 
> write something like VEST that would translate Vax and Alpha binaries 
> into x86 binaries?
> 
> Never heard of it, but to tailor a precompiled VAX/Alpha VMS binary for 
> our kernel on x86 would require a lot more than that: think virtual 
> memory and instruction translation (JIT?)

	There is only one VAX that can contains an alpha processor (VAX 10k), 
and I've never seen one of them with an alpha board. VAX and alpha codes 
are very different. To run a VAX binary on an alphaserver, you have to 
replace on the flight all opcodes (or run in a vurtual machine). When 
VAXen were replaced by Alphas, there are some cross compilers that can 
convert VAX binaries to alpha's (I have used in the past a utility that 
works on assembly output, but I have forgotten its name...).

> - I was under the impression 
> that the existing code could load and execute a precompiled VMS binary, 
> but I planned on doing this for our kernel anyways after we get it 
> running. Just don't expect a whole lot for the case of hardware drivers, 
> referring to an earlier discussion, but TCP/IP, filesystem and other 
> QIO/RMS-dependent code will hopefully be compatible.

	I don't understand. Today, we only work on amd64, right ? OpenVMS is 
only available on VAXen (until release 7.3), alpha and itanium (from 
8.2). Opcodes are strongly different and I don't see how an amd64 can 
directly run alpha, vax or ia64 opcodes.

>  > I haven't said that FreeVMS has to be only a 64 bits OS. I have 
> written that _in a first time_, we have to write a runable and stable 
> system on only one arch.
> 
> Hopefully we can all agree on x86? I don't exactly have a SPARC machine 
> laying around...

	We can, but don't forget that there are some new registers on amd64 
that don't exist in i386.

> Graham's resources will be quite interesting to read and design 
> according to - I will take note of them this weekend during my next long 
> coding session for this project.
> 
>  > Any special tool you will use for documentation? (Like doxygen, 
> kernel-doc)?
> 
> ...ASCII?
> 
> In all seriousness, I have written my documentation in plain text in my 
> IDE (Geany) as well as in-code comments clarifying functions and kernel 
> interfaces. I don't like formats like PDF or DocBook (SGML) because they 
> aren't all that portable and, frankly, a pain in the ass to read when 
> running console-only or without a proper interpreter.
> 
> Since we have a wiki, I vote for plaintext documentation with the easy 
> conversion to wiki-markup later by human hands as we make the 
> documentation public outside of the source code. If anyone has any other 
> ideas, let them be heard, but I'm just shooting for simplicity and 
> portability but I want to get the code properly documented without 
> detracting too much from the actual coding, and the in-IDE ASCII editing 
> allows me to do that while acheiving full portability.
> 
> But I'm not saying I'm closed to other options, as long as they are 
> simple to use and in a portable format.

	JKB