oops .. hit send too early -
Got it. The idea was not to encode more types - just reduce the
"complexity" of tagged pointers and remove the word aligned function
address restriction. Yes, a separate byte heap would totally be much more
complex. One of the reasons of this desire was to build
Got it. The idea was not to encode more types - just reduce the
"complexity" of tagged pointers and impose the word aligned function
address restriction but from what I gather. Yes, a separate byte heap would
totally be much ore complex. One of the reasons of this desire was to build
miniPicoLis
Nope. Polymorphic Inline Caching. And why shouldn't JIT compilers use MMU
"memory address violation exception" to check for end of range? Same for
TLB.
I could flood you with hundreds of papers about that. I am using that all
time.
Of you were right and such knowledgeable, PicoLisp would run
Hi Kashyap,
> Quick question - when you mentioned "doubling of space" - perhaps you were
> talking about systems that can only have WORD aligned pointers - is that
> correct?
Not only. Also on a byte-addressed machine, imagine if you make a cell of two
9-byte words, you get every cell aligned at
Hi Alex,
Quick question - when you mentioned "doubling of space" - perhaps you were
talking about systems that can only have WORD aligned pointers - is that
correct?
Regards,
Kashyap
On Wed, Apr 22, 2020 at 6:56 AM Guido Stepken wrote:
> Well, we have year 2020, not Dijksra 1978. Even embedded
On Wed, Apr 22, 2020 at 03:49:41PM +0200, Guido Stepken wrote:
> Well, we have year 2020, not Dijksra 1978. Even embedded systems have a MMU
> and you get "Memory Access Violation", so no pointer rage checks needed to
> be handled by CPU any longer.
Sigh, you don't understand at all how a Lisp
Well, we have year 2020, not Dijksra 1978. Even embedded systems have a MMU
and you get "Memory Access Violation", so no pointer rage checks needed to
be handled by CPU any longer. Those formerly needed range checks, eating up
clock cycles, now are deeply sticking in MMU and IOMMU ... Bang! -
Hi Alex,
> Yes, what Guido writes is nonsense. Fixed-sized address spaces are a
terrible
> solution. Doesn't scale, and is extremely inefficient due to the necessary
> pointer range checks.
>
> PicoLisp's way is far superior, because the tag bits come "free", they are
> implicit by the natural
I meat: "0xE000 for everything, that must be persisted to disk". There, of
course, you can also reserve three slots for float, integer, string ...
Best regards, Guido
Am Mittwoch, 22. April 2020 schrieb George-Phillip Orais <
orais.georgephil...@gmail.com>:
> Hi Guido,
> I think you mean 0xF000
Hi Geo,
> I think you mean 0xF000 for everything? This is indeed cool! but hmm does
> it limit the memory for each data type?
Yes, what Guido writes is nonsense. Fixed-sized address spaces are a terrible
solution. Doesn't scale, and is extremely inefficient due to the necessary
pointer range
Hi Guido,
I think you mean 0xF000 for everything? This is indeed cool! but hmm does
it limit the memory for each data type? Like what if the application uses
only integers so does it mean it cannot use the memory location for float
and strings?
BR,
Geo
On Wed, Apr 22, 2020 at 8:44 PM Guido
Hi Kashyap!
Reserving 1-3 bit from 32 or 64 bit register for special purposes, e.g.
indicating type or as persistence flag (ORM-wrapper) is the old fashioned
way. It unnecessarily costs cycles, reduces precision ...
The modern, "fully functional" (no state bits anywhere!) - and correct -
way
Thanks Alex,
I was thinking of increased memory space - not exactly doubling - I was
thinking it would just be one additional byte per CELL. Ofcourse this
additional byte would not have the same lifetime of the CELL so it should
not need any extra management.
I feel encouraged - I'll give it a
Hi Kashyap,
> About the the CELL having an additional byte, I meant that the CELL size
> would be 2*WORD + 1... that should work too right? I would not need any
> masking in that case.
I see. Yes, that would work. But it would either double the memory usage, or
require some management of this
Thanks Alex,
Yup, I can see what's going on now about RAM vs ROM :)
About the the CELL having an additional byte, I meant that the CELL size
would be 2*WORD + 1... that should work too right? I would not need any
masking in that case.
Regards,
Kashyap
On Mon, Apr 20, 2020 at 11:06 PM Alexander
Hi Kashyap!
Dividing up Lisp Cells (Atoms) in RAM/ROM - i think, you're referring to
this: https://picolisp.com/wiki/-A265.html has recently got another aspect:
https://en.wikipedia.org/wiki/Remote_direct_memory_access
RDMA, Remote Direct Memory Access.
With Picolisp and especially miniPicoLisp
Hi Kashyap,
> 1. About RAM vs ROM. Call me lazy but I would really appreciate a
> description of how the RAM vs ROM decision is taken here (and in general
> too..I mean, it is not clear to me how gen3m.c determines how something is
> never written to or not)
> if (x > 0)
>
Hi Alex et al,
I've been working on miniPicoLisp source with the idea of making it more
easy to understand - granted, it's really simple but it's simplicity may
not be apparent from looking at the source to some (such as myself). For
instance, it took me some time to get what's going on with the
18 matches
Mail list logo
