Emacs internals: Deconstructing Lisp_Object in C (Part 2)
thecloudlet.github.io
Emacs internals: Deconstructing Lisp_Object in C (Part 2)
1–10 of 23 posts
Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)
#2[flagged]
Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)
#3SBCL uses a single zero bit to tag integers. This trick means the representation of n is just 2n, so you can add the values directly without any decoding.
It obviously also means that all the other tag values have to use 1 as the last bit.
Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)
#4SBCL uses a single zero bit to tag integers. This trick means the representation of n is just 2n, so you can add the values directly without any decoding. It obviously also means that all the other tag values have to use 1 as the last bit.
That’s so cool. I did not know that.
Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)
#5Is AI able to measure the ratio of craft to cruft source lines of code in Emacs over its lifetime?
Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)
#6Is AI able to measure the ratio of craft to cruft source lines of code in Emacs over its lifetime?
Not AI, but I studied it extensively for about 6 months. I was trying to port Emacs to JS, line by line, about eight years ago.
I love Emacs' design. I think the cruft is minimal, and pretty much every line of code I studied had a good reason for being there.
And I also think there's a lot to learn from studying how Emacs is implemented. Few people will probably do this, but it was a nice experience for me. I learned a lot about gaps, text properties, how buffers are implemented, how the eval function works (it's surprisingly complicated between buffer-local variables and thread-local variables, but it's hard to think of a simpler alternative), and how intervals are implemented.
Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)
#7SBCL uses a single zero bit to tag integers. This trick means the representation of n is just 2n, so you can add the values directly without any decoding. It obviously also means that all the other tag values have to use 1 as the last bit.
Why do they use the bottom bit for tag and not the top bit?
Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)
#8Is AI able to measure the ratio of craft to cruft source lines of code in Emacs over its lifetime?
Not AI, but I studied it extensively for about 6 months. I was trying to port Emacs to JS, line by line, about eight years ago. I love Emacs' design. I think the cruft is minimal, and pretty much every line of code I studied had a good reason for being there. And I also think there's a lot to learn from studying how Emacs is implemented. Few people will probably do this, but it was a nice experience for me. I learned…
It’s not easy… I’m working to understand it. Recording the process through the way.
Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)
#9SBCL uses a single zero bit to tag integers. This trick means the representation of n is just 2n, so you can add the values directly without any decoding. It obviously also means that all the other tag values have to use 1 as the last bit.
Why do they use the bottom bit for tag and not the top bit?
Traditionally it has been done because the last three bits in an object pointer typically are always zero because of alignment, so you could just put a tag there and mask it off (or load it with lea and an offset, especially useful if you have a data structure where you'd use an offset anyway like pairs or vectors). In 64-bit architectures there are two bytes at the top that aren't used (one byte with five-level paging), but they must be masked, since they must be 0x00 or 0xff when used for pointers. In 32-bit archs the high bits were used and unsuitable for tags. All in all, I think the low bits still are the most useful for tags, even if 32-bit is not an important consideration anymore.
Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)
#10FYI thecloudlet, the last quote from a Reddit user at the end seems to have duplicated content (copy-paste error?)
I read both articles and am looking forward to your next! I’d be interested in understanding more about the relationship of EMacs to GCC since you noted the authors were the same and the internals were written with some compiler awareness.