Michael wrote: > I don't see a reason to do it at all - the pointer to it will sit in a > variable anyway, so what does it matter where in the address space it > is? Maybe they're trying to force the start to be aligned to something > bigger than PAGE_SIZE?
It doesn't have to be in a variable, in theory it could be optimized away by the compiler, improving speed of access to contents with also known offset. I don't know (yet) why it's done in CLISP, but that's a somewhat plausible reason. J. Hannken-Illjes wrote: > You try a value above VM_MAXUSER_ADDRESS: > > 0x0004000000000000 > 0x00007f8000000000 Ah, thank you a lot. Are these addresses (VM_MAXUSER_ADDRESS and VM_MIN_ADDRESS) somehow exposed in a header or queryable somehow? Then I could let configure give the job to decide which address to choose. Dan wrote: > MMAP_FIXED forces mmap to use the addr given or fail; without it, it > can act as if addr=0, and provide its own address. So, result might > != addr. Don't know if it would make a difference, but you could try > w/o fixed, and changing to see if result != addr, (and unmapping ) > Im guessing CLISP is specifying the addr so it can use the same address > each run, for space for cons-cells and such? And machine code refers? > to the address? Could you pass 0 as address, letting mmap pick the address, > then save result address somehow then, recompile with FIXED, and > that address? That's probably what I do in case the relevant address limits aren't somehow exposed. Johnny wrote: > I think that is hardware dependent. The OS might be somewhere in the > address space as well, just not accessible to user mode, for example. > I would not expect that to show up in the map. There might also be > limitations to what addresses actually can be mapped by the hardware. > > Which are additional reasons why it's probably better to let the OS > give you an address instead you you trying to pick one. Depending on the > hardware, there might actually be different ranges of addresses that you > will have issues with. That's a very good point. Kamil wrote: > I think you are probably aware of it, but CLISP already exists in > pkgsrc/lang/clist and works (builds) on NetBSD. Yes, I'm looking at what patches to CLISP are available "downstream", because ... Kamil wrote: > Are you working on upstreaming of the local patches? There has been > accepted a GSoC project to make the CLISP release (the latest one 2.49 > was in 2010), it should be the appropriate time for it. ... I'm the student working on the new release :) Robert wrote: > Both CMUCL and SBCL use the MAP_FIXED option to mmap(2) on NetBSD, it > works fine. > > Maybe try similar addresses to SBCL for CLISP, the core file for SBCL > is mapped starting at 0x1000000000. Thank you. That would have been the next thing to look at for me. As said above, I hope to be able to use VM_MIN_ADDRESS and VM_MAXUSER_ADDRESS. Best, Daniel
