freenode/#clasp - IRC Chatlog
Search
3:20:07
beach
Boke: The implementation should not but boxed and unboxed values in the same location.
3:21:45
Boke
i mean, right now cleavir has one kind of lexical location, and it's used for boxed values and for unboxed values
3:22:33
beach
Boke: Yes, and the implementation should make sure that a lexical location is used for only one purpose.
3:24:21
beach
It will be automatic if every array access that involves an array with unboxed values is wrapped in box/unbox pairs.
3:25:54
Boke
the thing that came up is that clasp allocates stack space for each lexical variable and the amount of space could obviously depend on the type
3:28:15
beach
What about the datum class? Sorry, you need to be more explicit with me. I am not smart enough to get the context myself. Especially not this early in the morning, before I finish my coffee.
3:28:48
Boke
as of yet we have done nothing. clasp doesn't use unboxed values and i haven't modified any code for them
3:30:21
Boke
well, he figured that because of the allocation thing, but i don't know how other translators would work enough to say one way or the other
3:30:29
beach
Boke: Yes, but it looks to me like drmeister might consider adding such things, and that worries me.
3:31:07
beach
So I am trying to make sure that it is understood that HIR was not meant to manipulate arbitrary machine numbers.
3:33:13
Boke
at hir level we only need to care about box/unbox in the understood way. typed lexical locations is about storage allocation at the turning-it-into-llvm level. so no hir involved
3:34:14
beach
I just want to make sure that drmeister shares this point of view. That wasn't clear from the exchange I read.
3:34:28
Boke
though, relatedly i'm not sure how aref/aset being lowered to mir is going to work, if at all
3:37:12
beach
How about this: Compute the base address of the contents of the array. Compute the offset from the dimensions and the array indices to be used. Use an instruction to access the location consisting of the sum of the two.
3:40:51
Boke
like, if we have specialized arrays with different element widths, we'll have a different memory offset. (aref byte-array x) looks x bytes ahead, but (aref general-array x) looks x words ahead, kind of thing?
3:41:54
Boke
so the MIR has to have some actual representation of the computation (which is probably just a shift)
3:43:30
Boke
what i tried first was having a general "memref" instruction that took any number of inputs, and had a list of shift amounts with one element for each input
3:44:08
Boke
and... i think i gave up on that because i realized i had to untag the index arguments but not the array argument, in clasp's particular arrangement of things. that could be worked around though
3:45:57
beach
Yeah, I think I said this before. The memref instruction dates from a time when I didn't realize HIR was necessary, and at that time, I didn't have a good grasp of what kind of instructions were required in general. If I were you, I would consider the memref instruction to be obsolete.
3:46:44
Boke
yeah. well, the ones that exist could never work for array access anyway, they only take one variable argument
3:49:39
Boke
I mean, from what you just said, would the way an array access works be that you have MIR arithmetic instructions operating directly on the array considered as an address?
3:50:45
beach
Sort of. Sometimes, like in SICL, the array object itself is not the base of the contents, so you would have to emit memref instructions to get to the contents first.
3:56:35
beach
Now, many processors, including the x86, have instructions that take both a base address and an offset, so it would probably be better to have a MIR instruction that does the same, rather than trying to construct such a target instruction from arithmetic+memref.
3:57:32
beach
The Intel manual says such a complex instruction is faster than it would be to do the arithmetic "manually".
3:58:27
Boke
as far as i understand, regular number arithmetic is sometimes compiled using the address computation instructions, even
3:59:31
beach
Yes, on x86 there is an instruction (forget the name, compute effective address, or something) that is often used for arthmetic.
4:06:45
Boke
well, for now i'm probably going to keep doing it in aref/aset, and not change cleavir, until i can figure out what to use mir for
6:31:08
drmeister
I'll add the instruction addresses and comments and switch the values to hexadecimal tomorrow.
6:33:50
Shinmera
Might be useful to be able to get the disassembly in the form of LLVM IR as well, though.
6:36:32
drmeister
Currently DISASSEMBLE disassembles to llvm-ir and you have to use that function above (llvm-sys:disassemble-instructions ...) to disassemble to assembly.
6:36:59
drmeister
I haven't figured out how to get the number of bytes in a function - only the pointer to the start.
6:37:11
Shinmera
Hm. Is an implementation allowed to add optional or keyword arguments to a function that is specified without?
6:39:39
Shinmera
Aaaand I don't have time to search the clhs for the relevant section right now. Gotta run to an appointment. Later!
6:39:54
drmeister
Normally - I would think not. But DISASSEMBLE is more of a utility. I'll ask in #lisp tomorrow what people think - if not I'll just write another DISASSEMBLE*
11:46:10
Bike
i think having extra keywords is okay. we already do for, for example, compile-file and make-hash-table
12:15:04
Shinmera
simply says "An implementation can have extensions, provided they do not alter the behavior of conforming code and provided they are not explicitly prohibited by this standard."
12:15:25
specbot
Documentation of Extensions: http://www.lispworks.com/reference/HyperSpec/Body/01_eac.htm
13:18:00
Bike
think i got aref with GEP working. time gain is negligible, but if it's about aliasing that wouldn't show up in my test.