You never had this constraint in standard C. You did, until C99, have to declare the variables at the start of a block, but this was still valid C even then:
if (b) goto x; { int y = 1; x: return y; }
Even without the corner cases related to declarations, being able to enter a block anywhere other than the start makes reasoning about control flow harder than it needs to be.
I don't know - between Java and Flash, it's hard to tell which has the worse security record. Though these days about the only Java applets on the web are malware, so at least you get a lower false positive rate by blocking them all.
My solution was to get the hell out of the valley. I transferred to a new location with my same company and had a blast
From my consulting days, I remember a lot of companies being delighted to pay 80% of a Bay Area salary to me when my cost of living was around 10% of the Bay Area. They paid less, I put vastly more into savings than if I'd been living in SF. I still don't really understand the attraction of living out there (it's fun to visit - I'm actually in the Bay Area this week - but a week or two a year is enough).
Bennett Haselton was never an editor, he was a 'frequent contributor' who treated Slashdot as his private blog and was routinely panned by the community.
There's a difference between the break and a goto: the break target can only go up an exact number of scoping depths. With goto, you can do horrible things like jump over the declaration of a variable. Consider this code:
if (b) goto x; int y = 1; x: return y;
Clang and GCC won't even warn when you do this, but if b is true then this code contains undefined behaviour (the initialisation of y is not reached - even though the initialisation is inline with the declaration). In contrast, the standard explicitly prohibits jumping over a declaration in other contexts. If you restructure the above example to use a switch statement to jump over the declaration of y, then you'll see the code rejected at compile time.
In this example, you get much cleaner code from inverting your if conditions so that they're checking for success, not failure, and the proceed version is inside the next indentation level. You can then cleanly see what failure condition corresponds to which cleanup, in both directions, using the indentation level. Linux developers are allergic to this for two reasons. The first is that they set their tab width to 8 and have an 80-column maximum line width, so code written with this kind of structure quickly runs out of horizontal space. The second is that GCC 1.x generated much better code from the goto version (since 3.0, probably 2.x but I've not actually tested it) it will generate byte-for-byte identical code from both.
Recursion used to be a lot faster on x86 then non-recursive solutions (to the extent that the Microsoft C++ compiler would turn iterative code into recursive) because stack pushes and pops were a lot cheaper than any other memory addressing mode (and are still single-byte instructions, so have good i-cache usage). On modern x86 chips, there's some fairly complex interaction between store forwarding and register rename logic that makes storing values relative to the stack pointer cheap, but manipulating the stack pointer expensive. Whether an iterative or recursive implementation will be faster depends a lot on the microarchitecture and it's generally not a big enough win to make the code less readable if one form is easier to understand than the other.
Embedded is a term that ranges from 4- and 8-bit microcontrollers with under 1KB of RAM up to storage appliances with multi-core multi-GHz CPUs and hundreds of GBs of RAM. There are very few generalisations that are true for that entire space.
This is true for a language like C, where you have strict constraints on the function call ABI. For languages that are designed with recursion in mind, it's common to transform a recursive call into a continuation passing representation. Called functions are then always tail called, but sometimes take a continuation as an extra argument (which they then tail call instead of returning). The last step prior to the back end will then turn some of these back into call-return structures to take advantage of the hardware's support for the stack.
There's a big difference between the two cases. Sony released an update that removed core features. Apple released an update that preserved the features, but removed the server part of support for the old version. No one complains if a company updates a protocol and pushes an update to the client, the complaint here is that they pushed a new client version and tied it to the new OS version, which they presumably did to reduce development costs (using the new APIs from the new OS and not having to maintain a separate code path for the old OS version). I doubt that this will stand up in court: Apple provides a free update that allows the feature to keep working, it's pretty hard to argue convincingly that they were required to do more than that - other companies have updated the server portion of a service and required a paid update to the client without being sued.
Unlike BitKeeper's equivalent, git submodules are not transparent. If you're using submodules, then you constantly have to be aware of the submodule work flow. You also need to decide up front how to split your repo. About the only thing I miss from svn is being able to keep everything related to a project in one big repo, and either check out the whole thing or some small sub-project, depending on what I'm working on.
Yes, that's what I said. When they design their cores, they have to do so with more than one fab technology in mind, so they can't do the Intel thing of carefully tuning their designs to the underlying process.
It's not quite that clear cut. The big win for RISC was that the decoder was a lot smaller (and didn't rely on microcode). That gave them a lot more area to add ALUs for the same transistor budget. As chip sizes increased, the decoder area went from being a dominant part of the core to a fairly small one, and a denser CISC instruction encoding meant that the extra i-cache that RISC chips needed used more area overall. Add to that, CISC had more headroom for microarchitectural improvements. For example, early RISC designs didn't have hardware division, so you implemented it as a sequence of simpler ops because you couldn't do it in a single cycle. With longer pipelines and better implementation techniques, CISC chips added hardware division without needing to change the ISA, RISC chips needed you to recompile your software to take advantage of it.
The flip side of this is power consumption. A modern RISC ISA, such as ARMv8, has very similar instruction density to x86 and still has a much simpler decoder. It's a richer instruction set (things like complex addressing modes, which provide a big performance win and were omitted from early RISC designs) are there, as are things like crypto acceleration and SIMD. At the high end, there isn't much difference, but in low power modes that complex decoder and microcode engine on x86 chips adds a noticeable amount to power consumption.
Yeah, but will commercial software vendors follow Apple down the garden path to an ARM future when the rest of the world (Linux and Windows) is still on x86?
Windows runs on x86 and ARM, though not many people run it on ARM. Linux is installed on at least one order of magnitude more ARM devices than x86. If anything, x86 is now a niche architecture for Linux.
hacked up libre office offered by zen ding dong jacnoff for arm that needs root access and web add's or a a 80$ copy of MS office on X86 that majority of the universe uses at this point
You realise that Microsoft ships Office for three different operating systems on ARM, I presume?
ARM has only been doing 64-bit out-of-order execution and branch prediction for two generations
That's a big combination of features. ARM has been doing branch prediction for a couple of decades. The Cortex A9 was their first out-of-order design. The A8 was two-way superscalar, but in-order. These were introduced in 2005 and (I think) 2010. 64-bit is newer, but in microarchitectural terms not nearly as big a jump as the others - data paths are wider, but that's basically it (and a load of the difficult things, like store multiple and the PC as a target for arbitrary instructions went away with AArch64). That said, it's all irrelevant because these are cores designed by Apple, not ARM. The Apple team includes people from their acquisition of PWRficient and a couple of other companies that have been designing superscalar chips (including some 64-bit ones) for well over a decade.
There are some real costs to x86. It's more fair to call the decoder a parser for x86 - instructions are between one and 15 bytes long, they map to between one and a few dozen micro-ops. You need to keep the decoder powered almost all of the time (and when it's unpowered, you need to have the trace cache, which contains decoded micro-ops, powered) that you're executing instructions. ARM (AArch64 and Thumb-2) instruction sets are tuned to give good cache usage, so the typical win of CISC over RISC in i-cache usage doesn't really apply.
That said, when you get up to desktop or server power consumption levels, the power consumption is dominated by the register rename engine and the ALUs. Here, Intel has an advantage over ARM because they control their process and integrate their chip design very closely with the fab technology. This lets them put analogue components for monitoring power consumption and power / clock gating throughout the chip. Dark Silicon (i.e. the end of Dennard Scaling) means that you keep getting more transistors to put in the IC, but you can't power more of them at a time. Being able to switch off parts of the chip faster than the competition means that Intel still has some advantages. Some of the ARM partners who design their own cores and control their own fabs could do this, but ARM licenses IP cores that are produced by multiple vendors with different processes. Apple is in a similar situation, as they're careful to have a second source for fabbing their ARM cores.
Not true. ARMv8 contains both AArch32 and AArch64. AArch32 ARMv8 is not the same as ARMv7, it adds several new instructions. M and R profile ARMv8 chips are all AArch32.
That's it. The vast majority of programs run exactly the same speed in 32-bit as they do in 64-bit, except they take up a bit more memory
That's not it at all. First, on a 64-bit system ASLR has a lot more bits to play with. In a 32-bit system, you're lucky to get 12 bits of entropy (Android gets 8 bits on 32-bit systems, which is one of the reasons StageFright was so bad: 256 probes took well under a second from JavaScript and pretty much guaranteed breaking ASLR). On a 64-bit system you can easily make the search space large enough to be infeasible to probe without the OS noticing something odd is going on.
When running Objective-C code, you can store small objects inside pointers. On 32-bit systems this basically lets you store small ints, which isn't that useful (I don't think Apple even bothers). With 64-bit systems, you can store 7-character ASCII strings, which is enough for a lot of dictionary keys. This makes comparisons cheaper, reduces memory consumption, and improves cache usage (when I added this optimisation to the GNUstep Objective-C implementations, I found that 5-20% of total object allocations were stored inside the pointers instead of on the heap for typical desktop workloads). Apple also stores the refcount embedded in the class pointer for objects on 64-bit systems which, again, improves performance and cache usage.
Supporting both AArch32 and AArch64 comes with several costs. ARMv8 makes both AArch32 and AArch64 optional (though they've now fixed the spec so you must implement at least one - until then I had the world's simplest ARMv8 compliant core...). Removing the AArch32 parts simplifies the silicon and improves power consumption. Not having to have 32-bit versions of all of the shared libraries installed means that you can dramatically reduce memory usage.
Multiple choice exams are among the hardest to write, unless you expect everyone to get close to 100%. It's easy to write a question and work out what the correct answer is. It's hard to pick 3-4 other answers (distractors) that look as if they might be the correct answer, if you misunderstand one particular thing. For the big exam boards, multiple choice exams typically take at least 3-4 times as long to prepare as ones with free-form answers (they're popular because the preparation costs are a one-off expense that doesn't scale with the number of people taking the exam, whereas the costs of marking scale linearly with the number of students and the constant multiplier per student is vastly lower with multiple choice, especially with CBT where it's almost zero). There's a bunch of recent research on designing multiple choice exams for use as part of the learning process, to specifically identify misunderstandings so that teachers can focus on the things that the students need help with.
Add to that, you need a variety of different item response curves for each question group so that you can use them to discriminate at the different grade boundaries.
Slashdot Mirror
Even without the corner cases related to declarations, being able to enter a block anywhere other than the start makes reasoning about control flow harder than it needs to be.
I don't know - between Java and Flash, it's hard to tell which has the worse security record. Though these days about the only Java applets on the web are malware, so at least you get a lower false positive rate by blocking them all.
My solution was to get the hell out of the valley. I transferred to a new location with my same company and had a blast
From my consulting days, I remember a lot of companies being delighted to pay 80% of a Bay Area salary to me when my cost of living was around 10% of the Bay Area. They paid less, I put vastly more into savings than if I'd been living in SF. I still don't really understand the attraction of living out there (it's fun to visit - I'm actually in the Bay Area this week - but a week or two a year is enough).
Observation: All women behave in an obnoxious manner towards you.
Hypothesis 1: The common factor in the interactions and cause of this behaviour is you.
Hypothesis 2: All women are misandrists.
I'd put money on hypothesis 1.
Bennett Haselton was never an editor, he was a 'frequent contributor' who treated Slashdot as his private blog and was routinely panned by the community.
As for multiple inheritance being bonkers. My car is a Honda and a vehicle registered in NJ. That's two hierarchies.
That's not an argument that multiple inheritance is needed, that's an argument that subtyping rarely fits real-world problem domains.
Clang and GCC won't even warn when you do this, but if b is true then this code contains undefined behaviour (the initialisation of y is not reached - even though the initialisation is inline with the declaration). In contrast, the standard explicitly prohibits jumping over a declaration in other contexts. If you restructure the above example to use a switch statement to jump over the declaration of y, then you'll see the code rejected at compile time.
In this example, you get much cleaner code from inverting your if conditions so that they're checking for success, not failure, and the proceed version is inside the next indentation level. You can then cleanly see what failure condition corresponds to which cleanup, in both directions, using the indentation level. Linux developers are allergic to this for two reasons. The first is that they set their tab width to 8 and have an 80-column maximum line width, so code written with this kind of structure quickly runs out of horizontal space. The second is that GCC 1.x generated much better code from the goto version (since 3.0, probably 2.x but I've not actually tested it) it will generate byte-for-byte identical code from both.
Recursion used to be a lot faster on x86 then non-recursive solutions (to the extent that the Microsoft C++ compiler would turn iterative code into recursive) because stack pushes and pops were a lot cheaper than any other memory addressing mode (and are still single-byte instructions, so have good i-cache usage). On modern x86 chips, there's some fairly complex interaction between store forwarding and register rename logic that makes storing values relative to the stack pointer cheap, but manipulating the stack pointer expensive. Whether an iterative or recursive implementation will be faster depends a lot on the microarchitecture and it's generally not a big enough win to make the code less readable if one form is easier to understand than the other.
Embedded is a term that ranges from 4- and 8-bit microcontrollers with under 1KB of RAM up to storage appliances with multi-core multi-GHz CPUs and hundreds of GBs of RAM. There are very few generalisations that are true for that entire space.
This is true for a language like C, where you have strict constraints on the function call ABI. For languages that are designed with recursion in mind, it's common to transform a recursive call into a continuation passing representation. Called functions are then always tail called, but sometimes take a continuation as an extra argument (which they then tail call instead of returning). The last step prior to the back end will then turn some of these back into call-return structures to take advantage of the hardware's support for the stack.
You used the word Linux a lot of times for a story that has absolutely nothing to do with Linux.
There's a big difference between the two cases. Sony released an update that removed core features. Apple released an update that preserved the features, but removed the server part of support for the old version. No one complains if a company updates a protocol and pushes an update to the client, the complaint here is that they pushed a new client version and tied it to the new OS version, which they presumably did to reduce development costs (using the new APIs from the new OS and not having to maintain a separate code path for the old OS version). I doubt that this will stand up in court: Apple provides a free update that allows the feature to keep working, it's pretty hard to argue convincingly that they were required to do more than that - other companies have updated the server portion of a service and required a paid update to the client without being sued.
Unlike BitKeeper's equivalent, git submodules are not transparent. If you're using submodules, then you constantly have to be aware of the submodule work flow. You also need to decide up front how to split your repo. About the only thing I miss from svn is being able to keep everything related to a project in one big repo, and either check out the whole thing or some small sub-project, depending on what I'm working on.
A corrupt system is still corrupt, even when one of the people abusing their power happens to be someone that I agree with.
Yes, that's what I said. When they design their cores, they have to do so with more than one fab technology in mind, so they can't do the Intel thing of carefully tuning their designs to the underlying process.
It's not quite that clear cut. The big win for RISC was that the decoder was a lot smaller (and didn't rely on microcode). That gave them a lot more area to add ALUs for the same transistor budget. As chip sizes increased, the decoder area went from being a dominant part of the core to a fairly small one, and a denser CISC instruction encoding meant that the extra i-cache that RISC chips needed used more area overall. Add to that, CISC had more headroom for microarchitectural improvements. For example, early RISC designs didn't have hardware division, so you implemented it as a sequence of simpler ops because you couldn't do it in a single cycle. With longer pipelines and better implementation techniques, CISC chips added hardware division without needing to change the ISA, RISC chips needed you to recompile your software to take advantage of it.
The flip side of this is power consumption. A modern RISC ISA, such as ARMv8, has very similar instruction density to x86 and still has a much simpler decoder. It's a richer instruction set (things like complex addressing modes, which provide a big performance win and were omitted from early RISC designs) are there, as are things like crypto acceleration and SIMD. At the high end, there isn't much difference, but in low power modes that complex decoder and microcode engine on x86 chips adds a noticeable amount to power consumption.
Yeah, but will commercial software vendors follow Apple down the garden path to an ARM future when the rest of the world (Linux and Windows) is still on x86?
Windows runs on x86 and ARM, though not many people run it on ARM. Linux is installed on at least one order of magnitude more ARM devices than x86. If anything, x86 is now a niche architecture for Linux.
hacked up libre office offered by zen ding dong jacnoff for arm that needs root access and web add's or a a 80$ copy of MS office on X86 that majority of the universe uses at this point
You realise that Microsoft ships Office for three different operating systems on ARM, I presume?
ARM has only been doing 64-bit out-of-order execution and branch prediction for two generations
That's a big combination of features. ARM has been doing branch prediction for a couple of decades. The Cortex A9 was their first out-of-order design. The A8 was two-way superscalar, but in-order. These were introduced in 2005 and (I think) 2010. 64-bit is newer, but in microarchitectural terms not nearly as big a jump as the others - data paths are wider, but that's basically it (and a load of the difficult things, like store multiple and the PC as a target for arbitrary instructions went away with AArch64). That said, it's all irrelevant because these are cores designed by Apple, not ARM. The Apple team includes people from their acquisition of PWRficient and a couple of other companies that have been designing superscalar chips (including some 64-bit ones) for well over a decade.
IBM, the company that has invested more in Java and Linux than almost any other company, is distancing itself from Microsoft? Tell me more!
There are some real costs to x86. It's more fair to call the decoder a parser for x86 - instructions are between one and 15 bytes long, they map to between one and a few dozen micro-ops. You need to keep the decoder powered almost all of the time (and when it's unpowered, you need to have the trace cache, which contains decoded micro-ops, powered) that you're executing instructions. ARM (AArch64 and Thumb-2) instruction sets are tuned to give good cache usage, so the typical win of CISC over RISC in i-cache usage doesn't really apply.
That said, when you get up to desktop or server power consumption levels, the power consumption is dominated by the register rename engine and the ALUs. Here, Intel has an advantage over ARM because they control their process and integrate their chip design very closely with the fab technology. This lets them put analogue components for monitoring power consumption and power / clock gating throughout the chip. Dark Silicon (i.e. the end of Dennard Scaling) means that you keep getting more transistors to put in the IC, but you can't power more of them at a time. Being able to switch off parts of the chip faster than the competition means that Intel still has some advantages. Some of the ARM partners who design their own cores and control their own fabs could do this, but ARM licenses IP cores that are produced by multiple vendors with different processes. Apple is in a similar situation, as they're careful to have a second source for fabbing their ARM cores.
True, 32-bit ARMs have stopped at armv7.
Not true. ARMv8 contains both AArch32 and AArch64. AArch32 ARMv8 is not the same as ARMv7, it adds several new instructions. M and R profile ARMv8 chips are all AArch32.
That's it. The vast majority of programs run exactly the same speed in 32-bit as they do in 64-bit, except they take up a bit more memory
That's not it at all. First, on a 64-bit system ASLR has a lot more bits to play with. In a 32-bit system, you're lucky to get 12 bits of entropy (Android gets 8 bits on 32-bit systems, which is one of the reasons StageFright was so bad: 256 probes took well under a second from JavaScript and pretty much guaranteed breaking ASLR). On a 64-bit system you can easily make the search space large enough to be infeasible to probe without the OS noticing something odd is going on.
When running Objective-C code, you can store small objects inside pointers. On 32-bit systems this basically lets you store small ints, which isn't that useful (I don't think Apple even bothers). With 64-bit systems, you can store 7-character ASCII strings, which is enough for a lot of dictionary keys. This makes comparisons cheaper, reduces memory consumption, and improves cache usage (when I added this optimisation to the GNUstep Objective-C implementations, I found that 5-20% of total object allocations were stored inside the pointers instead of on the heap for typical desktop workloads). Apple also stores the refcount embedded in the class pointer for objects on 64-bit systems which, again, improves performance and cache usage.
Supporting both AArch32 and AArch64 comes with several costs. ARMv8 makes both AArch32 and AArch64 optional (though they've now fixed the spec so you must implement at least one - until then I had the world's simplest ARMv8 compliant core...). Removing the AArch32 parts simplifies the silicon and improves power consumption. Not having to have 32-bit versions of all of the shared libraries installed means that you can dramatically reduce memory usage.
Add to that, you need a variety of different item response curves for each question group so that you can use them to discriminate at the different grade boundaries.