[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
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/
signature.asc
Description: This is a digitally signed message part.
- [gforth] Using Gforth with #! "shebang", David Kuehling, 2012/11/20
- Re: [gforth] Using Gforth with #! "shebang", Andrew Pennebaker, 2012/11/20
- Re: [gforth] Using Gforth with #! "shebang", Anton Ertl, 2012/11/21
- Re: [gforth] Using Gforth with #! "shebang", David Kuehling, 2012/11/21
- Re: [gforth] Using Gforth with #! "shebang", Bernd Paysan, 2012/11/21
- Re: [gforth] Using Gforth with #! "shebang", Anton Ertl, 2012/11/21
- Re: [gforth] Using Gforth with #! "shebang",
Bernd Paysan <=
- Re: [gforth] Using Gforth with #! "shebang", David Kuehling, 2012/11/21
- Re: [gforth] Using Gforth with #! "shebang", Bernd Paysan, 2012/11/22
- Re: [gforth] Using Gforth with #! "shebang", Anton Ertl, 2012/11/22
- Re: [gforth] Using Gforth with #! "shebang", Bernd Paysan, 2012/11/22
Re: [gforth] Using Gforth with #! "shebang", Bernd Paysan, 2012/11/21