gforth
[Top][All Lists]
Advanced

[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 
documentation.

> 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"
http://bernd-paysan.de/

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


reply via email to

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