[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gforth] Using Gforth with #! "shebang"

From: Bernd Paysan
Subject: Re: [gforth] Using Gforth with #! "shebang"
Date: Wed, 21 Nov 2012 18:28:11 +0100
User-agent: KMail/4.8.5 (Linux/3.4.11-2.16-desktop; KDE/4.8.5; x86_64; ; )

Am Mittwoch, 21. November 2012, 17:47:44 schrieb Anton Ertl:
> > would be even easier to implement, and then your multiarg shebang is
> > 
> > #! /bin/sh
> > #(
> > exec gforth-fast --options
> > exit
> > )
> And the "#0 [IF]" works even for existing Gforth installations, so it
> seems at least as good.

Probably not in gforth-0.6.0... but in general, I think all it needs is 

> Given that there is sp@ fp@ rp@ lp@, this is not safe in general.

Yes, and the error frames already use those, so it's really not possible.

> Also, the way recent Linuxes handle mmaps (no guard pages, unlike
> older Linuxes) has led us to allocate everything in one chunk, and
> then put guard pages in with mprotect or munmap.  One would have to
> make sure that there are guard pages after the copying, too.

Of course.

> > Resizing the dictionary would require to
> > reserve a large chunk of memory via mmap+mprotect, this is doable (this
> > will still allow you to catch errors from allocating too much).
> Actually, this is probably the way to go.  We use MAP_NORESERVE
> anyway, so we should be configuring really large areas by default
> (say, like -m 1G -d 64M -f 64M -r 64M -l 128M on 32-bit systems).

The stack defaults are used to create threads, as well (though you can 
override the defaults if you want).  On a 64 bit system, reserving 64MB per 
stack is fine, but on a 32 bit system, it would be too limiting for using 
multiple threads.

IMHO, in the "don't bury your tools" sense, we should also expose the 
mmap/mfree based allocation and deallocation to the user.  This is the only 
way to really give back allocated memory to the OS when it is no longer used.

> Up to now we configured relatively small sizes by default, and left it
> to installers on larger systems to choose larger sizes with
> "./configure FORTHSIZES=...", but most installations are probably on
> large systems through third-party distributors (e.g., Linux
> distributors) who don't use FORTHSIZES, while for systems like Windows
> where the large sizes may be problematic (not sure if it is), we are
> doing the configuration ourselves and could choose smaller sizes there.

If there will be problems on those platform, we can do something about it.

Bernd Paysan
"If you want it done right, you have to do it yourself"

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]