gsg

32 ms·

61.
by gsg 11y ago
The two-continuation style suggested there is familiar to me under the name "double barreled CPS", although usually in the context of compilation. Interesting to see it suggested for user code.
62.
by gsg 11y ago
Dependent types allow for this kind of thing. Another possibility that doesn't require such heavy language machinery is something like OCaml's private types, where the scope of unrestricted access is unsafe blocks rather than the
63.
by gsg 11y ago
Nice article, but the language embedded here is exactly the untyped lambda calculus, not a Lisp. You can tell because there are no tags: pair is given as \x y sel -> sel x y, which is indeed the textbook way to encode pairs but does not
64.
by gsg 11y ago
Perhaps mincaml: https://github.com/esumii/min-caml It's a small (few thousand lines), rather neat, weakly optimising compiler for a subset of OCaml, written in OCaml. It has more than one backend, a few optimisat
65.
by gsg 11y ago
Interesting. MLton did the basic-blocks-with-arguments thing too: http://mlton.org/pipermail/mlton/2007-February/029597.html http://mlton.org/pipermail/mlton/2003-January/023
66.
by gsg 11y ago
> extract the same information again in hardware It isn't necessarily the same information. OoO engines happily speculate through branches without waiting for a test value to become available, forward values based on exact addresses
67.
by gsg 11y ago
I don't think that needs to happen. From the article: "Basically, we re-enter a clone of the loop from above…. a clone specially made to be re-entered at any iteration" This is put forward as the explanation for how variables
68.
by gsg 11y ago
Populating x86-64 floating point registers is also an amusing subject. The obvious instruction for loading a (64-bit) float into an xmm register is movsd. With a memory source operand, the higher part of the register is zeroed, which is wha
69.
by gsg 11y ago
This is an interesting design question - which layer should be backwards compatible and under which significant freedom of design is allowed. I'm not at all sure that the best answer is "source code". For x86 CPUs the compati
70.
by gsg 11y ago
> In the name of software compatibility You say this as if it is a bad thing (or am I misinterpreting here?), but compatibility is enormously valuable. That's why the strategy of choosing compatibility over cleanliness of architectu
71.
by gsg 11y ago
Having TurboFan compile the interpreter from machine-independent templates is what struck me as unusual. The rest is familiar enough, true.
72.
by gsg 11y ago
Interesting decision. The architecture sounds a little unusual: "The interpreter itself consists of a set of bytecode handler code snippets, each of which handles a specific bytecode and dispatches to the handler for the next bytecode.
73.
The Evolution of V8 and the Challenges of Research in a Billion User VM [video](youtube.com)
53 points by gsg 11y ago|1 comments
74.
Digging into the TurboFan JIT(v8project.blogspot.com)
20 points by gsg 11y ago|0 comments
75.
by gsg 11y ago
DEC deliberately moved away from VAX to work on Alpha, which performed quite well for its time. John Mashey made some interesting comments on the (lack of) future prospects for the VAX here: http://yarchive.net/comp/vax
76.
by gsg 11y ago
The structured SSA building algorithm I had in mind has a fairly simple extension that covers break, continue, and early return. It's more complicated, but still way simpler than iterated dominance frontiers. > you can always comput
77.
by gsg 11y ago
Yeah. Even basic things like building SSA can be done more simply on "structured" CFGs. The benefits are enough that data structure and algorithm designs in the JVM compiler world often take advantage of assuming reducible control
78.
by gsg 11y ago
It's not true that traditional code generation approaches ignore this problem. Copy coalescing is a well-studied problem - the problem is that solving it optimally is expensive enough that compilers use heuristics[1]. Sometimes they do
79.
by gsg 11y ago
Calls and other instructions that use specific registers (variable shift and division on x86, for example) tend to ruin that ideal somewhat.
80.
by gsg 11y ago
I wonder what percentage of those xors are for generating zero? I would guess a large majority of them.
81.
by gsg 11y ago
Note that you don't need a dumb compiler, register pressure, or an instruction with physical register constraints to require a copy. Two-address instructions suffice: simply have a register for the first operand that contains a value t
82.
by gsg 11y ago
Fair enough! Good luck with your rewrite.
83.
by gsg 11y ago
That's an admirable sentiment, but aren't your hands tied by the promises made by the standard? In particular the addresses of elements are guaranteed to be stable, which would seem to prevent an implementor from relocating them t
84.
by gsg 11y ago
That doesn't quite fit with "you already know exactly what it does" - you left out a detail. Whether it is reasonable to leave that out or not, the point is that it takes a lot of text to unambiguously cover every possible fa
85.
by gsg 11y ago
Does it mutate the list in place or return a new one?
86.
by gsg 11y ago
The old UNCOL dream, still alive after all this time. You'd think people would learn.
87.
by gsg 11y ago
Multiple real implementations of register VMs have three operand instructions. Lua, Luajit and Guile are examples that I'm familiar with. For that matter, many ISAs feature three operand instructions. Even some of the recent extensions
88.
by gsg 11y ago
JIT compilers aren't really an argument either way, as you can do tracing or transform to an SSA graph from either representation quite easily. All the real complexity is further down the compilation pipeline. I (half) wrote a toy trac
89.
by gsg 11y ago
That would be very inefficient, because registers cannot be indexed. The dispatch you have to introduce to jump to code that references the right physical regs would murder you with mispredictions. Also, register VMs typically have three op
90.
by gsg 11y ago
Interesting. A while back I did some rough tests on search of arrays in depth first order. The hope was that the better contiguity (the next element in the array is the next element to test 50% of the time) would lead to better search perfo

More ›