Steel Bank Common Lisp

On Jan 23, 2008 10:34 AM, Peter Dillinger <pcd@...> wrote:
[...]
> students discovered, however, that it doesn't work under 64-bit
> windows.  when they try to load my saved image, they get something
> like
>
> | VirtualAlloc: 0x1e7.
> |
> | ensure_space: failed to validate 536870912 bytes at 0x09000000
> |
> | (hint: Try "ulimit -a"; maybe you should increase memory limits.)
>
> also, another student with 4G of memory got a similar error.  and a
> similar error arises if Data Execution Protection is enabled.
>
> questions:
>
> is win32 SBCL currently being tested on 64-bit versions of windows
> (which are supposed to be able to run 32-bit applications without
> modification-- ha!)?  what about 32-bit versions with > 2G memory
> installed?

Maybe this isn't exactly what you are talking about, but I can run
SBCL (1.0, 1.0.6, 1.0.9, 1.0.13) fine on 64-bit windows machine. (I am
running 32-bit windows so maybe this isn't your situation.)

-- 
Elliott Slaughter

"Any road followed precisely to its end leads precisely nowhere." -
Frank Herbert

On Thu, Jan 24, 2008 at 02:20:18PM -0800, Elliott Slaughter wrote:
> Maybe this isn't exactly what you are talking about, but I can run
> SBCL (1.0, 1.0.6, 1.0.9, 1.0.13) fine on 64-bit windows machine. (I am
> running 32-bit windows so maybe this isn't your situation.)

i'm rather certain it is not.  running 32-bit windows on a 64-bit
processor is, from a program's perspective, essentially the same as
running it on a 32-bit processor.

the only difference i could see would be access to SIMD instructions
only put on 64-bit chips that happen to also be available from 32-bit
mode.

-- 
Peter Dillinger
pcd@...
http://www.peterd.org

On 1/23/08, Peter Dillinger <pcd@...> wrote:

> i've deployed ACL2 (google it for info) to lots of students based on
> SBCL 1.0.9 for windows (since that was the latest binary
> distribution).  i found it to be quite stable (except w.r.t.
> breaks/errors; 1.0.13 seems to have fixed these issues), and i like
> the fact that it doesn't depend on a C compiler.
>
> students discovered, however, that it doesn't work under 64-bit
> windows.  when they try to load my saved image, they get something
> like
>
> | VirtualAlloc: 0x1e7.
> |
> | ensure_space: failed to validate 536870912 bytes at 0x09000000
> |
> | (hint: Try "ulimit -a"; maybe you should increase memory limits.)

As you may already know, SBCL currently has to reserve a contiguous
address space at a known address for its use -- this message is an
attempt to do that failing.

The failure is basically be that particular version of Windows loading
something else (iirc SHELL32.DLL is a common culprit) in that address
range before SBCL tries to reserve it.

...how much this has to do with Windows being a 64 bit version there
I'm not willing to guess at.

> also, another student with 4G of memory got a similar error.  and a
> similar error arises if Data Execution Protection is enabled.
>
> questions:
>
> is win32 SBCL currently being tested on 64-bit versions of windows
> (which are supposed to be able to run 32-bit applications without
> modification-- ha!)?  what about 32-bit versions with > 2G memory
> installed?

The amount of physical memory is not likely to have a great effect, but
I don't know enough about Windows to swear that it doesn't have any...

> does saving an image on one machine and loading it on another machine
> with a potentially different address space layout affect its ability
> to load?

No.

> have some of these issues been addressed since 1.0.9?  (i don't have
> ready access to these "odd" systems to test my 1.0.13 build very
> soon.)

I can't immediately think of anything likely to change these issues
much.

Two major options:

1. Try using eg. --dynamic-space-size 128 (or other number, big enough
   to run ACL2, small enough for there to be a contiguous chunk of
   address space starting at #x09000000 to be available.)

2. Rebuilding SBCL from the source, using David Lichteblau's relocation
   patches, which should remove the need for a contiguous address space.
   (I think someone reported Windows problems with the patch, but I
   also think David said they were unexpected, and that he was going to
   look at them?)

Other options include using the official source, but twiddling with the
hardcoded address space ranges in src/compiler/x86/parms.lisp, and
Various Magical Windows Tools some people have previously mentioned on
this list, which may be able to edit the sbcl.exe in a way that causes
Windows to leave the desired address space free.

> are there any plans to add Ctrl+C (ConsoleCtrlHandler) support?
> (right now i'm planning to deploy a version with a very simple patch
> that allows the main thread to ask periodically whether a console
> interrupt has happened, which allows me to cover about 75% of the
> cases i care about.)

I am not aware of any current plans to do so, but patches are certainly
welcome!

Note: it was approximately a year ago that I did any Windows work of note
on SBCL, and one of the things I looked at that point was ConsoleCtrlHandler.
IIRC it was quite unwilling to work with SBCL at that point, but I didn't
finish my investigation as to the why of it.

Cheers,

 -- Nikodemus

Nikodemus Siivola wrote:
> On 1/23/08, Peter Dillinger <pcd@...> wrote:
> 
>> i've deployed ACL2 (google it for info) to lots of students based on
>> SBCL 1.0.9 for windows (since that was the latest binary
>> distribution).  i found it to be quite stable (except w.r.t.
>> breaks/errors; 1.0.13 seems to have fixed these issues), and i like
>> the fact that it doesn't depend on a C compiler.
>>
>> students discovered, however, that it doesn't work under 64-bit
>> windows.  when they try to load my saved image, they get something
>> like
>>
>> | VirtualAlloc: 0x1e7.
>> |
>> | ensure_space: failed to validate 536870912 bytes at 0x09000000
>> |
>> | (hint: Try "ulimit -a"; maybe you should increase memory limits.)
> 
> As you may already know, SBCL currently has to reserve a contiguous
> address space at a known address for its use -- this message is an
> attempt to do that failing.
> 
> The failure is basically be that particular version of Windows loading
> something else (iirc SHELL32.DLL is a common culprit) in that address
> range before SBCL tries to reserve it.
> 
> ...how much this has to do with Windows being a 64 bit version there
> I'm not willing to guess at.
> 
>> also, another student with 4G of memory got a similar error.  and a
>> similar error arises if Data Execution Protection is enabled.
>>
>> questions:
>>
>> is win32 SBCL currently being tested on 64-bit versions of windows
>> (which are supposed to be able to run 32-bit applications without
>> modification-- ha!)?  what about 32-bit versions with > 2G memory
>> installed?
> 
> The amount of physical memory is not likely to have a great effect, but
> I don't know enough about Windows to swear that it doesn't have any...
> 
>> does saving an image on one machine and loading it on another machine
>> with a potentially different address space layout affect its ability
>> to load?
> 
> No.
> 
>> have some of these issues been addressed since 1.0.9?  (i don't have
>> ready access to these "odd" systems to test my 1.0.13 build very
>> soon.)
> 
> I can't immediately think of anything likely to change these issues
> much.
> 
> Two major options:
> 
> 1. Try using eg. --dynamic-space-size 128 (or other number, big enough
>    to run ACL2, small enough for there to be a contiguous chunk of
>    address space starting at #x09000000 to be available.)
> 
> 2. Rebuilding SBCL from the source, using David Lichteblau's relocation
>    patches, which should remove the need for a contiguous address space.
>    (I think someone reported Windows problems with the patch, but I
>    also think David said they were unexpected, and that he was going to
>    look at them?)
> 
> Other options include using the official source, but twiddling with the
> hardcoded address space ranges in src/compiler/x86/parms.lisp, and
> Various Magical Windows Tools some people have previously mentioned on
> this list, which may be able to edit the sbcl.exe in a way that causes
> Windows to leave the desired address space free.
> 
>> are there any plans to add Ctrl+C (ConsoleCtrlHandler) support?
>> (right now i'm planning to deploy a version with a very simple patch
>> that allows the main thread to ask periodically whether a console
>> interrupt has happened, which allows me to cover about 75% of the
>> cases i care about.)
> 
> I am not aware of any current plans to do so, but patches are certainly
> welcome!
> 
> Note: it was approximately a year ago that I did any Windows work of note
> on SBCL, and one of the things I looked at that point was ConsoleCtrlHandler.
> IIRC it was quite unwilling to work with SBCL at that point, but I didn't
> finish my investigation as to the why of it.
> 
> Cheers,
> 
>  -- Nikodemus
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Sbcl-devel mailing list
> Sbcl-devel@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-devel
> 
For what it's worth, (I'm not sure how much) on win64 boxen I changed
src/compiler/x86/parms.lisp to the attached patch. I'm not sure what 
actually lives in the dynamic space, but I'm inclined to guess it's 
WoW32, hence the high failure rate on win64 boxen. HTH

I'm keeping an eye on mingw64 but as yet, I don't think its mature 
enough to be in with a chance of compiling SBCL.



-- 
+--------------------------------------------------------+
|Cyborg Animation Programmer    |    johnc@...|
|http://badbyteblues.blogspot.com -----------------------|
+--------------------------------------------------------+

On 1/27/08, John Connors <johnc@...> wrote:

> For what it's worth, (I'm not sure how much) on win64 boxen I changed
> src/compiler/x86/parms.lisp to the attached patch. I'm not sure what
> actually lives in the dynamic space, but I'm inclined to guess it's
> WoW32, hence the high failure rate on win64 boxen. HTH

So these setting are at least somewhat good for 64bit Windows? Can
someone confirm if they are good for 32bit Windows as well?

Adding a build-option to use these instead (win64 instead of win32)
is simple enough, though.

(Dynamic-space is basically most of the code and data of the lisp image.)

Cheers,

 -- Nikodemus

On 1/29/08, Nikodemus Siivola <nikodemus@...> wrote:
> On 1/27/08, John Connors <johnc@...> wrote:
>
> > For what it's worth, (I'm not sure how much) on win64 boxen I changed
> > src/compiler/x86/parms.lisp to the attached patch. I'm not sure what
> > actually lives in the dynamic space, but I'm inclined to guess it's
> > WoW32, hence the high failure rate on win64 boxen. HTH
>
> So these setting are at least somewhat good for 64bit Windows? Can
> someone confirm if they are good for 32bit Windows as well?

Apropos: what does uname -m return on 64 bit Windows? Or rather, which
command-line tool can tell us that the host is a 64 bit Windows?

Cheers,

 -- Nikodemus

"Nikodemus Siivola" <nikodemus@...> writes:

> Apropos: what does uname -m return on 64 bit Windows? Or rather, which
> command-line tool can tell us that the host is a 64 bit Windows?

the PROCESSOR_ARCHITECTURE environment variable has the value "AMD64"
on 64-bit Windows (probably something else on Itanium, but who cares).

(and shouldn't the relocation patch fix this all for good?)

cheers,
--m

Op zondag 3 februari 2008, schreef Michael Livshin:
> "Nikodemus Siivola" <nikodemus@...> writes:
> > Apropos: what does uname -m return on 64 bit Windows? Or rather, which
> > command-line tool can tell us that the host is a 64 bit Windows?
>
> the PROCESSOR_ARCHITECTURE environment variable has the value "AMD64"
> on 64-bit Windows (probably something else on Itanium, but who cares).
>
> (and shouldn't the relocation patch fix this all for good?)
>
> cheers,
> --m

Actually, PROCESSOR_ARCHITECTURE just has value "x86" but 
PROCESSOR_ARCHITEW6432 has value AMD64.
My uname -a tells me:
MINGW32_NT-5.2 XP64 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 Msys
so uname -m says i686.

Peter

sbcl-devel@... writes:

> Op zondag 3 februari 2008, schreef Michael Livshin:
>>
>> the PROCESSOR_ARCHITECTURE environment variable has the value "AMD64"
>> on 64-bit Windows (probably something else on Itanium, but who cares).
>
> Actually, PROCESSOR_ARCHITECTURE just has value "x86" but 
> PROCESSOR_ARCHITEW6432 has value AMD64.
> My uname -a tells me:
> MINGW32_NT-5.2 XP64 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 Msys
> so uname -m says i686.

oh nice.

according to this bit of official wisdom, you are correct:
http://blogs.msdn.com/david.wang/archive/2006/03/26/HOWTO-Detect-Process-Bitness.aspx

that is: if you look inside the "Environment Variables" tab of "My
Computer", you'll see PROCESSOR_ARCHITECTURE=AMD64.  *but* query that
variable from inside a 32-bit executable (of which your mingw "getenv"
command is an example), you'll get "x86", at which point you should
check the value of PROCESSOR_ARCHITEW6432.  which is also, presumably,
what the mingw implementation of "uname -m" does.

cheers,
--m

Op zondag 3 februari 2008, schreef Michael Livshin:
> sbcl-devel@... writes:
> > Op zondag 3 februari 2008, schreef Michael Livshin:
> >> the PROCESSOR_ARCHITECTURE environment variable has the value "AMD64"
> >> on 64-bit Windows (probably something else on Itanium, but who cares).
> >
> > Actually, PROCESSOR_ARCHITECTURE just has value "x86" but
> > PROCESSOR_ARCHITEW6432 has value AMD64.
> > My uname -a tells me:
> > MINGW32_NT-5.2 XP64 1.0.11(0.46/3/2) 2007-01-12 12:05 i686 Msys
> > so uname -m says i686.
>
> oh nice.
>
> according to this bit of official wisdom, you are correct:
> http://blogs.msdn.com/david.wang/archive/2006/03/26/HOWTO-Detect-Process-Bi
>tness.aspx
>
> that is: if you look inside the "Environment Variables" tab of "My
> Computer", you'll see PROCESSOR_ARCHITECTURE=AMD64.  *but* query that
> variable from inside a 32-bit executable (of which your mingw "getenv"
> command is an example), you'll get "x86", at which point you should
> check the value of PROCESSOR_ARCHITEW6432.  which is also, presumably,
> what the mingw implementation of "uname -m" does.
>
> cheers,
> --m

I build the latest git version of SBCL now and then and upload to 
http://www.peerweb.nl/sbcl/ . I haven't done a lot of testing, but with the 
win64 patch SBCL is still able to build SBCL, on 32 bits and 64 bits windows.

All contribs except sb-simple-streams build fine, which is a known issue. A 
lot has improved since 1.0.9, still there is the issue of GUIDs recreated 
every time you create the sbcl.wxs file (supposedly not a good idea if you 
want to update parts of the install). So you'd need a list of GUIDs to use 
for every component (SBCL_Base and every test-passed contrib item).

It seems somebody wants to have .lisp and .fasl files associated with sbcl.exe 
too, which is not included in the setup process (yet).

I did some patching to exclude unneeded files from the installer.
I have tried to add an icon to the installer as described here 
http://wix.sourceforge.net/manual-wix2/wix_xsd_icon.htm, but I am not 
sattisfied with the location of the icon in the shortcut to sbcl.exe 
(%APPDATA%\Microsoft\Installer\{<GUID>}\sbcl.ico) and attempts to set the 
location of the icon for the shortcut to another location failed. I think 
it's still best if the icon were just linked into the executable, if an icon 
is something you'd want. The dependency is in a platform specific file 
anyway, all you need is the icon file. I sent a patch for this earlier:
http://sourceforge.net/mailarchive/message.php?msg_id=200708301348.07685.sbcl-devel%40peerweb.nl
(but sf seems to have lost attachments to messages in the mailinglist archive)
All patching is in sbcl-1.0.14.10-windows.patch at my /sbcl/ web location.

Peter

sbcl-devel@... writes:
> It seems somebody wants to have .lisp and .fasl files associated
> with sbcl.exe too, which is not included in the setup process (yet).

I think there used to be an association to .lisp, but that was removed
since some users considered it somewhat antisocial for SBCL to set up
that association unconditionally (and stealing it from other
implementations). And it doesn't seem like a horribly useful thing to
do: at least I would expect clicking on a Lisp file to open it in an
editor, not to run it.

-- 
Juho Snellman