Why is it important: technology already and some years ago provides the
non-volatile RAM, which saves its state after the full power down (Intel
Optane, HPE NMDIMM's). What is much more important that modern OSes a long time
ago provide the ability to extend any program address space via `mmap`
I don't want to access it -- I want to use Nim as a persistence-enabled
language, with all its power of dynamic structures (mapped to SSD or NVDIMM).
But I don't think it is possible -- I must implement not only custom GC but
integrate these "offset/based pointers" into the Nim core or at least
Maybe I should especially note: the PMEM base address moves randomly across the
address space between every program run. That's why generic pointers not
acceptable -- they use the absolute address, but I must address relatively to
the BASE randomly moving in memory.
Thinking about the x86_64 architecture and C compilers, there is a case of
using memory segments, and dedicated segment register (for the single mmap
area) -- it looks able to work at the hardware level. Is this possible in Nim
and C compiler to utilize this mode?
Good day
I'm trying to implement a very light object database in Nim and found some
problem: Is it possible to introduce a new custom pointer type into the
language?
I need of long 64-bit pointer to address mmaped data spaces into the process
memory relative to the `mmap` base address. The hig
I'm doing something like that myself, with Python as host language, metaLayer
built atop of object graphs for model-driven programming (not! UML/OMG trash),
and source-level translation into a set of target languages (Django, JS,
Makefile, embedded C). It looks great and handy even at the very b
Why not write Nim compiler like this? Cross-compiler written as a library over
an interpreter. The coding style will change, but it will have much more power.
We write some script code, which does low stuff, build models as data
structures, for example, classical AST but not limited. Then, run c
