Comment Re:bit3h (Score 1) 65
Comms Section. He's conjuring up a co-ordinated crapflood of said ASCII art and press releases in an article defined in the encrypted message you see.
Comms Section. He's conjuring up a co-ordinated crapflood of said ASCII art and press releases in an article defined in the encrypted message you see.
Python brought a unique mixture of functional and imperative syntax and semantics
Various ML dialects had that before Python. The thing Python brought was a poor performance implementation of a language from the C++ school of language design: keep adding features without regard to how they interact and expect programmers to know all of them (if they ever work with anyone else) but only use a subset if they don't want totally unmaintainable code.
I finally got the full texts of Nobots and Mars, Ho! to display well on a phone. My thanks to Google for showing me how, even if the way they present the information is more like trial and error, but it's actually easy once you jump through all their hoops. I'll make it easy.
Regarding the ISA changes, let me explain further. For the cases you've mentioned we offer a software/hardware compatibility strategy which includes trap-and-emulate, trap-and-patch, and binary translation
For the branch instructions with the reused opcodes, this means that you need to do it up front. This means that things like JVMs and anything else with a JIT requires rewriting. This is where a big part of the cost of the software ecosystem comes from. It also means that disassemblers and debuggers (which are another big investment) also need significant rewriting, rather than just adopting.
Trap and emulate and trap and patch will only work if your MISPr6 processors have a special mode that will trap on any instructions that have had their opcodes reused. In such a mode, trap-and-patch usually won't work, because the compact branch instructions that are intended for use in the patching are in this set.
The new ISA is a lot nicer than classic MIPS, but it's almost as much effort to support in software as RISC V or ARMv8. This is part of the reason why we (with my FreeBSD hat on) have been working closely with Cavium on ARMv8 recently. Existing customers for Cavium's MIPS parts (certain storage and networking vendors) have looked at MIPSr6 and seen that the cost of migrating their code from MIPS III or MIPS64r1 to MIPSr6 is about the same as the cost of migrating to ARMv8. They've also seen the lack of serious investment in LLVM (until very recently, and even then it's far smaller than ARM alone - Apple, Google and ARM are investing an order of magnitude more effort than the MIPS ecosystem) and decided that it's worth working out the cost of an ARMv8 migration.
I mentioned this to Daniel over a year ago, but apparently ImagTec decided that keeping their customers' customers on MIPS wasn't a priority.
There are two problems with this idea. The first is that EMPs, like other EM phenomena, disperse via an inverse square law. Anything high enough to be line-of-site to the ground in most of the USA would need to have an enormous explosive yield (even by nuclear weapon standards). There are some designs that try to channel more energy into the EMP than normal, but they're very complex to build (a good 10-20 years more R&D beyond the Fat Man / Little Boy style bombs).
The second problem is the delivery. Iran does not have a significant ballistic missile capability. Getting something into space above the USA would require launching something in a suborbital trajectory. A very high suborbital trajectory if it were intended to explode that high up. The size of such a rocket would be such that it would be pretty hard to miss on satellite observation. The time in the air would give the US a very long time to formulate a response and destroying it would be relatively easy (remember, the problem with strategic defence shields in the cold war was not shooting down a missile, it was shooting down the large number of real and decoy rockets that the Soviet Union was capable of launching).
I was really surprised to learn recently that Chrome's support for OS X 10.6 is one of the main things blocking Skia from adopting C++11 library features (i.e. the things that make C++ not completely suck as a language). 10.6 has been officially unsupported for over a year and the last security update was a few months before that. It has known security holes (including one from missing bounds checking in DMA requests to the GPU that allows privilege escalation and might be exploitable from WebGL). Keeping these machines on the Internet is not really doing anyone a favour.
It's also a bit surprising that Chrome on 10.6 can't just bundle a copy of libc++.dylib, since none of the system APIs are C++ and the only problem with linking libc++ and libstdc++ is if you use standard library types at library boundaries.
Showing an industrial core is not really possible. MIPSfpga is actually simpler than BERI in a number of ways (though, being written in Verilog, likely to be much harder to understand than something like BERI or Rocket). A real core aimed at anything other than the embedded microcontroller market is going to be impossible to get access to. The kind of things that are substantially different from BERI or Rocket are the high-end out-of-order superscalar chips that no company is going to show you without paying a very big license fee.
For example LibreOffice was forked from OpenOffice because to much potential contributors was frustrated by the way the OpenOffice maintainers was with them in the past.
There's a lot more politics to it than that. LibreOffice started as Novell's Go-OO fork, which contained things covered by MS patents that could not be upstreamed because the indemnity only covered Novell. They managed to spin it very well about wanting to avoid Oracle being in control though...
Does RISC-V follow the MIPS instruction set AT ALL?
It's an entirely new ISA that is intended to be freely licensable.
The site says variable 32/64/128 bit address space - does that mean the ALU and registers are statically or dynamically configurable to have variable lengths?
There are 32-bit and 64-bit variants of the ISA (128-bit is coming). It also includes a variable-length instruction encoding (though currently all instructions are 32 bits) so that it's easy to extend (finding gaps in the MIPS opcode space can be challenging).
The hardest part of climbing the ladder of success is getting through the crowd at the bottom.