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.
