sklogic

46 ms·

541.
by sklogic 11y ago
Hipster kids can't code (efficiently, or at all, depending on your definition). In other news, Pope is catholic.
542.
by sklogic 11y ago
I do not want to spam with links to my projects (and to get banned for this), but sometimes it is relevant to mention them, as in this thread.
543.
by sklogic 11y ago
My research is on hierarchies of composable domain-specific languages (see github, account 'combinatorylogic').
544.
by sklogic 11y ago
VLIW is many times cheaper (in terms of power and area) than OoO. It is not going anywhere from the low budget range.
545.
by sklogic 11y ago
Yes, but now you can safely use a nice and clean subset without ever touching any dark corners.
546.
by sklogic 11y ago
Well into C++14, but yet this outdated myth of an unbearable "complexity". This is not the language you knew.
547.
by sklogic 11y ago
JavaScript is not particularly abstract and not that high level, so it's not surprising you can stuff it into some relatively low level environments. But yet, you can go even further down with something like Lua or even Python, which
548.
by sklogic 11y ago
It's very, very far from attiny85 or even things like PIC32 or ESP8266. 64Mb RAM, a 32bit MIPS and all that stuff. It's an order of magnitude larger than the minimum you'd need for javascript.
549.
by sklogic 11y ago
Come back when your crappy monstrous javascript runs on my attiny85.
550.
by sklogic 11y ago
And with REPL and debugger requirements it is even easier to implement a compiler than an interpreter. Pattern matching must be compiled anyway, even if the rest is interpreted, same for the static typing.
551.
by sklogic 11y ago
Although VC4 is capable enough to run simple GLSL shaders, it is not possible to compile a generic C (or OpenCL) code efficiently.
552.
by sklogic 11y ago
Writing an interpreter is much, much harder than implementing a simple, straightforward compiler. Interpreter is unavoidably convoluted, it is full of very complex things like environment handling, it cannot be split into smaller parts in a
553.
by sklogic 11y ago
There is even a better trick - ditch the lexer altogether.
554.
by sklogic 11y ago
There is no reason whatsoever for the so called "general purpose" languages to exist at all, no matter old or new ones. But, LLVM is a very useful tool for implementing DSLs.
555.
by sklogic 11y ago
In my experience such languages are very dangerous and it is better to have a chain of more restrictive languages instead. Most passes only make sense in a fixed sequence anyway. LLVM is infanously broken in this regard, btw., there are too
556.
by sklogic 11y ago
Passes need to be simple. Not even functional - just a plain term rewriting. Although, my approach allows to analyse sufficiently imperative passes too: I've got special cases for "collectors" (lists accumulating ordered data
557.
by sklogic 11y ago
Yes, I implemented exactly this approach. But for the binary expressions I am using Pratt, it is faster and easier to construct left-associative nodes.
558.
by sklogic 11y ago
I'm not using Nanopass directly, I've got my own similar framework (developed independently). It is using an IR which allows to easily compare the visitor shapes (i.e., source AST, target AST, traversing order, omitted nodes), and
559.
by sklogic 11y ago
> that don't use an AST at all but generate machine code directly during parsing It is not any different. A "sufficiently smart" compiler must be capable of fusing the lowering passes straight into a parser. Parsing is not
560.
by sklogic 11y ago
Yes, I am using this approach exclusively. Nanopass (or similar frameworks like MBase) is making it very easy to introduce as many languages as you like in between your passes. It really helps that they are different, you always know which
561.
by sklogic 11y ago
But you should not write your compiler the same way you write your ordinary, complex, convoluted, Turing-complete programs. Compilers are far simpler than that. You do not need a Turing-complete language to write a compiler.
562.
by sklogic 11y ago
> Plain English is hardly succinct and precise either. But so far it's the best form of communication we've got.
563.
by sklogic 11y ago
> if you are thrashing a single graph over-and-over again, you are doing many passes. A single "pass" can be thrashing a graph many times too, think of the things like instcombine (in LLVM parlance) or ADCE. Essentially, compil
564.
by sklogic 11y ago
It is much more memory-efficient than thrashing a single graph over and over again. Rewriting and compacting trees is good for cache locality. Also, for the trivial rewrites (e.g., variable renaming) your compiler can safely choose to repla
565.
by sklogic 11y ago
PEG (Packrat) is hot now.
566.
by sklogic 11y ago
This is the only sane approach. Small passes are easy to write, easy to understand and easy to reason about. And if yoy worry about performance, your compiler can fuse passes together in many cases.
567.
by sklogic 11y ago
And it is much closer to plain English than all that too nested languages. And most of the code must be like English, not like arithmetic expressions.
568.
by sklogic 11y ago
3D printing is great for molds (lost plastic / lost wax process), for the things you won't be able to make with your simple tools. It is also great for making and adapting tools.
569.
by sklogic 11y ago
The real game-changer is yet to happen. The missing bits of technology are printing the circuits (embedding the wiring, ideally with something more conductive than a paste or conductive ink) and combining a robotic, CV-guided pick and place
570.
by sklogic 11y ago
> it starts as slots for function pointers in structs in C It was built around lambdas in Smalltalk long before that. Simula (about 4 years older) had a more typical class-based OO with vtables and a proper subtyping already. Long before

More ›