Re: [Sbcl-devel] Windows port based on MS tools progress

[Robert R. <ro...@rf...>]

Nathan Froyd wrote:
> On Wed, Jan 6, 2010 at 2:38 AM, Robert Roessler<ro...@rf...>  wrote:
>> So, it is now based on Nasm, which has simple, readable syntax, happens
>> to be based on "Intel" operand ordering and instruction naming, and runs
>> everywhere [I think we care about].  Since I did keep the changes
>> minimal, the C-style comments are still there, as are the #includes and
>> simple #defines - so the make step for building this uses CPP.  But the
>> complex, multi-line #defines become Nasm macros - there is no other choice.
>
> I am not a fan of this change.  It adds an unnecessary dependency on
> Nasm on every x86oid platform *and* another dependency to the
> toolchain for which this work is being done.  This seems inelegant.

Maybe, and maybe not... at least we seem to agree on one thing: there 
should only be one version of the .S file (for the x86 platform).

In any case, MASM (from Microsoft) is iffy - its future is unknown, it 
hasn't been reliably appearing in developer tool sets, and isn't being 
sold by MS - but neither was it open-sourced.

So, stipulating for the moment at least some undesirability in choosing 
MASM as the tool (along with the obvious issue of it being only 
available in DOS/Windows versions - when it is available at all), and 
the premise of this particular porting/updating exercise being to NOT 
use gcc, we have some choices... of which Nasm is a decent example.

> I think there are two better ways forward here:
>
> 1) Move as much of the assembly file as possible into
> src/assembly/x86/*.lisp.  This change should be straightforward for a
> number of functions.  Routines called from C might be tricky to
> handle, but I think they are doable (this might requiring some mucking
> about for people doing relocatable cores development, though).
>
> Since moving *everything* may not be possible (a quick scan suggested
> that you could, though I haven't examined in detail), the second
> solution may be preferred:

Indeed - the assembly low-level modules exist for a reason, and it isn't 
merely historical. ;)

> 2) Abuse the preprocessor and #ifdef'ize x86-assem.S so that it can be
> compiled by gcc/gas and (with appropriate preprocessing as a separate
> build step, which IIUC you are already using) MASM.

Right.  Besides going to the effort to in essence create a 
domain-specific language for which no demand actually exists, you would 
have the added bonus of an unmaintainable mess - sweet!

Seriously, this is a single executable file, no bizarre support 
structure required (in general - as already mentioned, because of the 
way this particular project has evolved, use of CPP is needed), it's 
fast, it supports a huge number of output object formats, and it cleanly 
the solves a perennial question: to add the "_" character or not?

>> On Monday, I got successful links... if I run sbcl.exe, it of course
>> tries to load the core file from the sbcl version used for bootstrapping
>> (1.0.29) - which isn't going to work. :)
>>
>> While I am replacing the last few fragments of inline assembly with
>> "function-lets" in x86-assem-msvc.S, it would be cool if someone that
>> knows SBCL (and particularly its bootstrapping process) could give a few
>> tips on where and how I am going to come up with a useful core file.
>
> What do you mean "where and how"?  Do you mean where it's going to be
> located in the build tree (output/sbcl.core)?  Or are you asking for a
> checklist of "things that I might have to debug"?  Or something else?
> You can use the --core command-line option to specify the core file
> for your newly-built SBCL to load.  (You probably also want to use
> --no-userinit to avoid loading any fasls you had built for your
> current SBCL.)

Sometimes a question about coming up with a core file is just a question 
about coming up with a core file... so I looked again at the set of 
scripts used in the overall build, and noticed that things are stopping 
just BEFORE make-host-2 - which is where a "cold" core file would have 
been created.

Just *one* little error line from the MSYS nm version used at the end of 
make-target-1... ;)

This seems a bit odd, as my early tests seemed to show that the MSYS nm 
handles [at least some] Windows executables without problems - so I will 
examine the exact linker options I am using.  And let's not forget that 
I haven't yet finished replacing all of the [commented-out] inline 
assembly sequences with useful pieces of code, so this whole thing is 
not really expected to be fully operational yet anyway.

Robert Roessler