Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Comment Re:Microsoft (Score 3, Insightful) 149

Windows Phone is pretty nice. It's main drawback is the lack of apps (which is hard to fix, as no one wants to develop for a platform with few users and no one wants to buy a phone with no software). It's main problem selling is that people associate it with Windows on the desktop, which is a usability disaster that somehow manages to get worse each version, in spite of having passed the point where people thought it couldn't get any worse some time ago.

Comment Re:steve ballmer's legacy gets one last sucker pun (Score 2) 149

Around 2005, Nokia had a shiny new kernel (Symbian EKA2), designed from scratch to scale to future mobile systems with a good security model, clean abstractions, and power management built in at all layers. It was still hampered, however, by userspace APIs that were designed for a far more memory-constrained environment. Their solution to this involved multiple phases. Their first part was to try to replace the kernel with Linux. This did not go well. They then had no idea how to design a new set of userland APIs, so they set up multiple teams internally competing. These teams were very good at sabotaging each other, but not so good at bringing a usable product to market.

Elop came in when Nokia had failed to produce anything to compete with the iPhone or even with a moderately decent Android handset. He managed to persuade Microsoft to buy Nokia for what now turns out to be a significant multiple of their real value. Of all the companies that benefitted from this, Microsoft was pretty low down the list.

Comment Re:The solution nobody asked for (Score 1) 149

Furthermore Google is basically giving Android away

Half true. If you want to ship Android, it's free: go to AOSP, download, tweak to your device, ship. If, on the other hand, you want the Google Play store, then you have to pay Google, agree to ship other Google apps in the default firmware install, and agree not to ship competing apps in a few categories in the default install.

Microsoft lacks the design culture and brand to compete with Apple on the high end

A lot of that is marketing. It's far more a brand problem than a design culture. In terms of usability, I'd place Windows Phone a little bit ahead of iOS at the moment (which surprised me a lot, because Windows is a UI clusterfuck on the desktop, OS X is worse than it was but still in a completely different league to Windows 8.1 - I've not tried Windows 10 yet). Possibly MS moved all of their competent HCI people to the mobile team, or possibly management doesn't care as much about mobile so doesn't insist on multiple layers of design by committee. No one who's used Windows on the desktop would go out of their way to buy a Microsoft product though.

Comment Re:Microsoft (Score 4, Informative) 149

Symbian EKA2 was a great kernel design for mobile (and still does security and power management better than Linux), but a lot of the Symbian userspace APIs were designed at a time where 1MB of RAM was a lot, 4MB was huge. When 64MB was entry level, they were really showing their age: saving 1MB at the cost of a big increase in developer effort wasn't worth it. Nokia needed to provide a modern API and a clean migration path. They provided neither and they set up groups within the company competing to provide both and actively sabotaging each other. Maemo/Meego is an example of this: Switching from GTK to Qt shortly after launching the product doesn't instil developer confidence.

Windows Phone actually made sense for Nokia: they needed a software stack that let them differentiate themselves (and no one else seemed to be using WP) and they had managed to set up their corporate structure in such a way that it was impossible for them to develop it themselves. Some of their apps were really nice (their maps app, which was just bought by a consortium of German car makers was a lot better than the Apple or Google offerings, for example).

Comment Re:You are not qualified to debug your own code (Score 1) 247

For some insight into this, check out the classic book "Graphics Programming Black Book" which is available online in many places for free (such as ) Chapter 17 (on the well known "game of life") is good on this, but the entire book is a good read.

Please don't. The advice in that book (or, that chapter, at least) is great, if you're targeting a 486 with VGA graphics and a compiler from around 1995. Some of the advice is still good, but it's interleaved with advice that will result in much slower code (though the advice to always profile first may save you there!) and so it would be very hard to read that book without already understanding optimisation and come away more informed.

Comment Re: Compiler optimizer bugs (Score 2) 247

The worst bug I had to fix recently was in some hand-written assembly where the immediate in a store and a load overflowed and the assembler silently truncated it. I read the code multiple times and it was only when I traced the execution and looked at the disassembly that it became clear that the assembly and disassembly didn't show the same thing. This caused crashes, but it was in context switch code, so it only happened in processes that happened to use those particular registers and often quite a long way after returning to the process.

Comment Re: Compiler optimizer bugs (Score 1) 247

That's not debugging a compiler bug, that's step one in producing a reduced test case, which is step one in debugging a compiler bug. It's also starting from the easiest kind of compiler bug to fix (ones where it causes a crash at all, and within that category, ones where the crash and the miscompilation are in the same place).

Comment Re:Passing Parameters with Side Effects (Score 4, Insightful) 247

The order of parameter evaluation is one that bites a lot of people because most compilers do it the expected way. When you're walking an AST to emit some intermediate representation, you're going to traverse the parameter nodes either left-to-right or right-to-left and most compiler IRs don't make it easy to express the idea that these can happen in any order depending on what later optimisations want. If they have side effects that generate dependencies between them (as these do) then they're likely to remain in the order of the AST walker. Most compilers will walk left-to-right (because a surprising amount of code breaks if they don't), but a few will do it the other way.

To understand why this is in the spec, you have to understand the calling conventions. Pascal used a stack-based IR (p-code) and had a left-to-right order for parameter evaluation, which meant that the first parameter was evaluated and then pushed onto the stack, so the last parameter would be at the top of the stack. The natural thing when compiling Pascal (as opposed to interpreting the p-code) was to use the same calling convention, with parameters pushed onto the call stack left to right. Unfortunately, C can't do this and support variadic functions (not: some implementations wanted to do this, which is why the C spec says that variadic and non-variadic functions are allowed to use completely different calling conventions), because if the last variadic argument is the top of the stack then there's no way to find the non-variadic arguments unless you also do something like push the number / size of variadic arguments onto the stack.

This meant that C implementations tended to push parameters onto the stack right to left. This is less of an issue now that modern architectures have enough registers for most function arguments, but is still an issue on i386. Because of the order of the calling convention, it's more efficient on some architectures to evaluate arguments right to left. Some compilers that are heavily performance-focussed (GPU and DSP ones in particular, where they don't have a large body of legacy code that they need to support) will do this, because it reduces register pressure (evaluate the rightmost argument using some temporaries, push it to the stack, move onto the next, reusing all of those temporary registers).

Comment Re:Is return value optimisation a bug? (Score 1) 247

It's called copy elision and it is part of the C++ spec. The spec specifically says that compilers may (but are not required to) implement it, meaning that the compiler is completely free to do different things within the abstract machine at different optimisation levels. It's definitely a bug, but unfortunately it's a bug in the C++ standard. Any sane spec would either require the compiler to implement it or prohibit it - either would be fine (with C++11, prohibiting it would make sense as returning an r-value reference and doing move construction ought to give the same benefit).

Comment Re: Compiler optimizer bugs (Score 2) 247

Most compiler bugs are not that difficult to debug

Another compiler guy here: Some compiler bugs are not that difficult to debug if you have a reduced test case that triggers the issue. Most are caused by subtle interactions of assumptions in different optimisations and so go away with very small changes to the code and are horrible to debug (and involve starring at the before and after parts for each step in the pipeline to find out exactly where the incorrect code was introduced, which is often not where the bug is, so then backtracking to find what produced the code that contained the invalid assumption that was then exploited later).

Unix will self-destruct in five seconds... 4... 3... 2... 1...

Working...