libera/#sicl - IRC Chatlog
Search
3:07:13
beach
hayley: You didn't say anything about my suggesting to return additional values by calling a named function.
3:09:08
hayley
It would definitely work. We could probably remove one layer of indirection by having, say, INITIALIZE-RETURN-VALUES cache the vector of additional return values in a location.
3:18:52
beach
What I was thinking was that we could create an initial system that allows only as many return values as there are registers for it, and leave the named call as an unconditional jump that, if taken, will fail.
3:20:28
beach
We could even use the registers that used to be callee-saves for more return values so that it would be even less likely that we would bump into that limitation.
3:22:17
hayley
Interesting idea. I wouldn't know if all systems in SICL (or the subset you want to test with) only use five or fewer return values, but some profiling of the HIR evaluator could provide how many return values are actually used.
5:03:31
beach
For my physical exercise today, I was watching a video related to RISC-V, and that made me thinking that, for detecting overflow of fixnum addition and subtraction, it can become important for type inference to determine whether fixnums are negative or not.
5:06:10
beach
The general overflow check takes two more instructions in RISC-V (in addition to the arithmetic operation and the branch), but no more instructions are required if the sign of one operand is known.
5:10:40
moon-child
on the mill, there is an addition instruction that will fault if it overflows, so you don't need _any_ extra code to check for overflow
5:19:20
beach
I always hesitate when the operating system gets involved. Same thing for read/write barriers and such.
5:22:52
hayley
Would there be room in an instruction encoded in your favourite instruction set to implement an instruction like "add and branch on overflow"?