Live data from Hacker News

Emacs internals: Deconstructing Lisp_Object in C (Part 2)

thecloudlet.github.io

11–20 of 23 posts

Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)

#11
post #3

SBCL 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 also implies that NIL cannot be represented as 0, which is a pity since testing the Z flag would be quick. I'd think someone ran the numbers and found the chosen encoding superior, but that would have been long ago (in the CMUCL code base).

Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)

#12
post #3

SBCL 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 also implies that NIL cannot be represented as 0, which is a pity since testing the Z flag would be quick. I'd think someone ran the numbers and found the chosen encoding superior, but that would have been long ago (in the CMUCL code base).

I suspect with modern CPU pipelining and branch prediction that most of the (very interesting) debates about exactly how to tag values and pointers have become inconsequential above the noise level.

Would love to see recent work demonstrating this isn’t true!

Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)

#13

FYI 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.

Thank you for the kind reminder! I have removed the duplicate.

You made a great point. Since the original authors are the same, the fundamentals of the Emacs C core are indeed highly compiler-optimized. I hope I can come up with a way to fully understand and write about that history and relationship. (But to be honest, diving into that level of compiler history is a really hard topic to tackle!)

Thanks for the great inspiration and for taking the time to read!

Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)

#14

FYI 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.

Thank you for the kind reminder! I have removed the duplicate. You made a great point. Since the original authors are the same, the fundamentals of the Emacs C core are indeed highly compiler-optimized. I hope I can come up with a way to fully understand and write about that history and relationship. (But to be honest, diving into that level of compiler history is a really hard topic to tackle!) Thanks for the great…

One similarity I noticed was the intermediate representation from GCC frontend looks and feels very Lispy. Could be just a coincidence too.

Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)

#15

Is 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…

Why were you trying to port it to JS?

Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)

#16
post #15

Earlier quoted context omitted.

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…

Why were you trying to port it to JS?

It was fun, and I wanted to see how far I could get. Plus emacs in a browser without emscripten was appealing to me.

Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)

#17

Earlier quoted context omitted.

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.

I'd like to hear about it as you go! If you have any questions, definitely contact me. Love me some emacs.

Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)

#18

Earlier quoted context omitted.

It’s not easy… I’m working to understand it. Recording the process through the way.

I'd like to hear about it as you go! If you have any questions, definitely contact me. Love me some emacs.

Thanks!

Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)

#19
post #3

SBCL 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?

The sibling comment explains why we prefer to use the lower bits as a tag (these are guaranteed to be zero if the value is a pointer on a 64-bit system).

Another reason why we wouldn’t want to use the top bit is that, as the parent comment suggested, the tagged pointer representation of a fixnum integer isn’t a pointer at all but is instead twice the number it represents. Generally speaking, we represent integers in twos-complement representation which uses that top bit to determine if the value is positive or negative.

Re: Emacs internals: Deconstructing Lisp_Object in C (Part 2)

#20
You only need one bit tag and it is for number.

Symbols are just list of numbers. Variable is just a nameless place in memory, but often associated with a symbol.

Numbers in symbols are printed out as ASCII-characters when it seems appropriate, like after SETQ.

Or we could decide that number-list that ends with 0 and contains only range(0x21,0x7F) is printed out as symbol. Does not matter, it is just syntactic sugar.

And We do not need strings for much anything. We could of course decide that number-list with ord('"') is printed out as string. The reader could also follow this protocol.

I had all this figured out at one time. And I dont remember any major issues. B-)

Post reply on HN