Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror

Comment: Re:Technically C++ (Score 1) 168

by TheRaven64 (#49620005) Attached to: Singapore's Prime Minister Shares His C++ Sudoku Solver Code

General hint: If your functions are so long that having to (suppose this was indeed the case) declare/define all your variables at the top becomes a serious annoyance, then chances are that your functions are too long/do too much. Fix that instead.

More general hint: The principle of minimum scope exists for a reason. Declare your variables at the point where they can be initialised, not at some arbitrary point and you make life easier for people trying to understand the lifetime of the variable.

Comment: Re:Haskell? (Score 1) 135

by TheRaven64 (#49591845) Attached to: Paul Hudak, Co-creator of Haskell, Has Died

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.

Comment: Re:This is a response to RISC-V (Score 1) 63

by TheRaven64 (#49586045) Attached to: Imagination To Release Open MIPS Design To Academia

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.

Comment: Re: gosh (Score 5, Informative) 162

by TheRaven64 (#49584201) Attached to: The United States Just Might Be Iran's Favorite New Nuclear Supplier

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).

Comment: Re:Safari Does (Score 1) 153

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.

Comment: Re:gosh (Score 4, Insightful) 162

by TheRaven64 (#49583817) Attached to: The United States Just Might Be Iran's Favorite New Nuclear Supplier
Even if we didn't nuke Iran in response to an attack on Israel, you really don't want to be using high-yield nuclear weapons on someone that close to you - fallout blows in the wind quite a long way. The USA, Russia, India, and China are all good targets for strategic nukes, but smaller countries are likely to end up not containing the effect and Iran would be very unpopular if they covered their neighbours in radioactive dust. Given that they're already quite unpopular with their arabic neighbours, they'd likely expect a fairly large conventional response if they fired nuclear weapons anywhere in the middle east.

Comment: Re:Why? (Score 1) 223

by TheRaven64 (#49583787) Attached to: Windows 10 Can Run Reworked Android and iOS Apps
My girlfriend has one (she wanted one with a good camera and the Nokia Lumina some-unmemorable-number had the best one). The UI is nicer than any other phone I've used, but the selection of apps is a big limitation. Around half of the things that I use on a regular basis on my Android phone have no Windows phone equivalent. Being able to run Android apps would make it much more attractive.

Comment: Re:The problem with open-source MIPS clones (Score 1) 63

by TheRaven64 (#49583775) Attached to: Imagination To Release Open MIPS Design To Academia
BERI (our processor) has register renaming, forwarding, branch prediction, and so on (and can boot a full 64-bit OS), but it is not exactly like an industrial processor because it simply doesn't make sense to use the same techniques when targeting an FPGA as an ASIC. For example, most of our TLB is direct mapped, because block RAMs are very cheap on an FPGA so we can have 128 TLB entries in a BRAM and look them up based on a hash of the virtual address. Some techniques such as the nearly-associative memory stuff from UPenn can improve this. On an ASIC, this would be a silly way of doing it, as TCAMs are cheap (on an FPGA, they use large numbers of logic units and so burn through area very quickly in comparison to using the BRAM blocks). Generally, people who prototype ASICs on FPGA don't care much about the performance of the FPGA instantiation (or the cost, as the most expensive FPGAs are orders of magnitude cheaper than a fab run).

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.

Comment: Re:We all agree on ONE thing (Score 1) 177

by TheRaven64 (#49575473) Attached to: When Enthusiasm For Free Software Turns Ugly
The Ribbon wasn't too bad as an idea. Unifying the toolbar and menu bar makes a lot of sense, though on small-screen devices it was a problem. The thing that made it a UI disaster was automatically moving things around, breaking muscle memory and making it impossible to use anyone else's version of Office.

Comment: Re:How a project is maintained (Score 1) 177

by TheRaven64 (#49575467) Attached to: When Enthusiasm For Free Software Turns Ugly

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...

Introducing, the 1010, a one-bit processor. 0 NOP No Operation 1 JMP Jump (address specified by next 2 bits)

Working...