Nathan Froyd wrote:
> On Wed, Jan 6, 2010 at 2:38 AM, Robert Roessler<robertr@...> 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
Just *one* little error line from the MSYS nm version used at the end of
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.