Mill Computing, Inc. › Forums › The Mill › Tools › Compilers › Specialized Address Operations
- AuthorPosts
- #312 |
It was briefly mentioned in the metadata talk: There are specialized oprerations to do address artithmetic (kind of seems a logical conclusion considering you have separate instruction streams and decoders and fucntional units for normal arithmetic and everything dealing with addresses).
The interesting part about this is that address arithmetic can ignore certain bits in an operand, freeing them up for use in garbage collectors. I’m assuming the loads and stores can do this too.
This is of course also very useful for tagged data types that are primarily used in the functional languages. Having specialized operations there that obviate the need of additional instructions would be very helpful in those kinds of compilers.
The question then is of course how many and which bits can be ignored that way. On 32 bit architectures both haskell and many lisps tend to use 3 bits for tags. On 64 bit architectures 4 would be the natural choice, due to the natural alignments of pairs and closures/thunks respectively.
The three event bits in a pointer could be used as tags if the GC isn’t using them for garbage collection support. Mill pointers are always 64 bits. If is made enough of a difference I suppose we could be talked into one more bit 🙂
It would be possible to add a few metadata bits, or steal the floating-point metadata bits, for use as tags. However, the tags would be lost when the pointers are stored to memory, because memory has no metadata. Any ideas on what might be done about that?
I don’t think it would be a good idea to expose the internal use metadata to the programmer without any defined interface, which memory access basically would mean. I think it’s a good distinction to have hardware controlled flags and software controlled flags. Starting to mix them likely would be the start of a whole new set of headaches.
As for using more than 3 bits as tags: in ghc, the tags are used to encode the number of arguments to an unvisited thunk of lazy evaluation and whether it already has been evaluated. If I remember the white paper correctly 4 bits instead of 3 bits would push the case coverage of 70% to well over 90%.
- AuthorPosts
You must be logged in to reply to this topic.