sklogic

82 ms·

781.
by sklogic 11y ago
Every EE company I worked for used source control (perforce, git or svn). And a typical Verilog module is far longer than 1000 lines.
782.
by sklogic 11y ago
If "simpler" = mipsy then yes. If "mipsy" = "closer to hardware" then definitely not.
783.
by sklogic 11y ago
> Modern desktop CPUs are incredibly fast and run circles around modern FPGAs Yep. At a tiny price of tenths of W of TDP. FPGAs shine in communication, not in computing. Fast isolated memories, wide channels (as wide as you like), etc.
784.
by sklogic 11y ago
Why? It's very intentionally not MIPSy . ARMv8 removes anything that may dictate any microarchitecture decisions, while MIPS exposes it in an ISA (delay slots and all that). Even predication had been killed for this reason (it's
785.
by sklogic 11y ago
It's trivial to beat a generic CPU by 1000x with a specialised ASIC or even an FPGA in many cases (think cryptography, for example).
786.
by sklogic 11y ago
The future might be in an FPGA fabric tightly coupled with generic RISC cores (things like Zynq SoCs, but with a tighter integration, allowing a direct access from FPGA to the CPU internal registers, pipelines, etc.). Bigger macro cells (li
787.
by sklogic 11y ago
And why exactly an embedded programmer should read "Effective Java"?
788.
by sklogic 11y ago
You do not understand macros at all. One should always prefer macros to anything else. Macros must be used to implement hierarchies of composable eDSLs - by far the most powerful and advanced way to handle abstraction. Functions are not a
789.
by sklogic 11y ago
Comefrom is a mainstream now, not a joke any more. See the phi nodes in SSA.
790.
by sklogic 11y ago
I am totally going to use this approach in a production code. Because I am using generated code a lot.
791.
by sklogic 11y ago
> But only a small percentage of us can think in code We always think in code. A plan for a day is a code (and nobody ever use graphical diagrams for it). A cooking recipe is a code (plain text, never a diagram). A legal document is a
792.
by sklogic 11y ago
Saying that visual programming is the future is like saying that comic books will eventually replace all that boring 'tl;dr' walls of text. The truth is - people think in text . Visual abstractions are only suitable for a tiny su
793.
by sklogic 11y ago
In the old days things were supposed to just work. `./configure && make && make install` should always have worked around any local peculiarities.
794.
by sklogic 11y ago
Btw., VPU had been reverse-engineered to a degree, should be sort of possible to roll out your own bootstrap now: https://github.com/hermanhermitage/videocoreiv
795.
by sklogic 11y ago
Why would anybody be surprised by a pumpkin-positive cop? They're explicitly selected this way: http://abcnews.go.com/US/court-oks-barring-high-iqs-cops/sto...
796.
by sklogic 11y ago
Nitpicking: it's a VPU which runs the bootstrap blob, not the QPU (the latter is well documented and fairly open, unlike the former).
797.
by sklogic 11y ago
I'm talking about the recovery, not the messages - things like "skip to the next ';' and continue parsing a statement". > or any parser generator for that matter PEG-based generators can be just as good as handcr
798.
by sklogic 11y ago
LL(1) cannot recover that easily, which makes error reporting less useful.
799.
by sklogic 11y ago
An optimised Packrat is very efficient (especially when combined with Pratt), and the error handling can be on the same level as the best handcrafted professional parsers (like Clang or gcc) - it is easy to mix the recovery rules and arbitr
800.
by sklogic 11y ago
That's exactly how I use Prolog - embedded in the other languages. It is especially invaluable inside compilers (alongside with an optimised Datalog). And I had to extend the default unification for implementing some exotic type system
801.
by sklogic 11y ago
Have you seen Nanopass or MBase? They address this very question.
802.
by sklogic 11y ago
Btw., you do not need a Turing-complete language to build a compiler. It is much better to use a non-Turing-complete one, ideally, a total language.
803.
by sklogic 11y ago
Why do I need any OO in the first place, if the only value they can offer is in a poor man substitute for modules? I'd rather use the proper modules instead, with generic (i.e., inherently anti-OO) features.
804.
by sklogic 11y ago
Yes, it got macros, so you can build something similar to Nanopass framework on top of it easily.
805.
by sklogic 11y ago
ML got ADTs and pattern matching out of the box. Fine. With Lisp you can quickly build your own ADTs, with some enhanced functionality which is not possible in *ML family. See a couple of examples of this: [1] http://www.cs.india
806.
by sklogic 11y ago
I am not talking about any "cool features" in particular. My point is that for the large systems you need a decent module system and namespaces, not the OOP. The fact that most of the statically typed OO languages also provide t
807.
by sklogic 11y ago
Yes, makes sense... These units are accessible via (undocumented) intrinsics in some OpenCL implementations (or in GLSL), but, unfortunately, there is no portable solution. And the FP precision requirements in the OpenCL standard are way to
808.
by sklogic 11y ago
> Either way, my point is the "object" metaphor isn't really all that specific I still don't see how Plan9 is built on "objects". > functional operating systems I doubt functional metaphors are of any use
809.
by sklogic 11y ago
Many GPUs used to have a tiny, fast and very imprecise SFU - it's ok for GLES but useless for anything else.
810.
by sklogic 11y ago
Unix is fairly uniform, and not object-oriented. Plan9 is even more uniform and still not object-oriented. Lisp machines did not feature too much of an OO neither, and yet had a very unified interface to all the OS entities. Other than that

More ›