The patriarchy is crumbled and will die off with those that are 45+.
And you had me all the way up until you had to discriminate against me based on my age alone...
Not all us 46-year olds are as bad as you think. Just so you know. Oh, and now you've had your say, get off my lawn, etc.
Much of the later complexity didn't exist in the late 70s.
Yes, I should have said that I put RISC as beginning with Hennessy & Patterson's work, that became MIPS and SPARC respectively. So we're a bit later than that. And of course when I said "compiler" I meant "optimizing compiler". Basic compilation as you say, was not a problem on CISC, but everybody observed that the instruction set wasn't really used. I remember reading VAX code from the C-compiler (on BSD 4.2) when I was an undergrad and noting that the enter/leave instructions weren't used. My betters answered: "Of course it isn't, they put so much useless stuff in there that it's much too slow..." (Only they didn't use the word "stuff"...)
But yes, the x86 is perhaps more "braindead" than "CISC" from that perspective, I was actually thinking VAX and it's ilk as they were what "RISC" came to replace, since the x86 wasn't a serious contender for workstations/minicomputers when they entered the arena. It was strictly for "PCs", which were a decidedly lesser class of computer, for lesser things. If anything RISC replaced the MC68000 and similar in the workstation space. And even though that was CISC, it was of course a much nicer architecture than Intels ever were, or became.
The downside of having few registers in the ISA is it means the compiler may have to choose instruction ordering based on register availability or worse still "spill" registers to memory to fit the code to the available registers.
Yes, but the score boarding takes care of those spills as well. The processor won't actually perform them. But, whether they're visible or not, the compiler still has to optimise as if they're there in order to have a chance to wring out the maximum performance, so whether they're visible or not turns out to not mean that much in practice, rather, keeping them invisible isn't that much of a gain, as the compiler will have to assume that they're backed by invisible ones anyway and you'll take a substantial performance hit if they were ever to go away. (Which they won't as they take up next to no real estate today anyway.)
Yes, simplicity of design was important, but the simplicity was to free up chip resources to use elsewhere, not to make it easier for humans to design it.
Well, yes. I think we're forgeting one of the main drivers for RISC, and that was making the hardware more compatible with what the then current compilers could actually fruitfully use. Compilers couldn't (and typically didn't) actually use all the hideously complex instructions that did "a lot" and were instead hampered by lack of registers, lack of orthogonality etc. So there was a concerted effort to develop hardware that fit the compilers, instead of the other way around, which had been the dominating paradigm up to that point.
Take for example the MIPS without interlocked pipe-line stages. That was difficult for a human assembly coder to keep track of, but easy for a compiler, and it made the hardware design simpler and faster, so that's the way they went. (In fact, the assembler put in no-ops for you to fix inject pipeline stalls in order for your code to make sense when you programmed it in assembly. That made the object dump show stuff you didn't put there which was a bit disconcerting...
CISC ISAs may have individual "complex" instructions, such as procedure call instructions, string manipulation instructions, decimal arithmetic instructions, and various instructions and instruction set features to "close the semantic gap" between high-level languages and machine code, add extra forms of data protection, etc. - although the original procedure-call instructions in S/360 were pretty simple, BAL/BALR just putting the PC of the next instruction into a register and jumping to the target instruction, just as most RISC procedure-call instructions do. A lot of the really CISCy instruction sets may have been reactions to systems like S/360, viewing its instruction set as being far from CISCy enough, but that trend has largely died out.
I know you say "current", but one of the original ideas behind RISC was also to make each instruction "short", i.e. make each instruction take one cycle, and reduce cycle times as much as possible so that you could have really deep pipelines (MIPS), or increase clock speed. Now, while most "RISCs" today, sort-of follow this idea, by virtue of the ISA having been made with that in mind in the old days, i.e. load-store etc. they're typically not as strict about it (if they in fact ever where). I guess the CISC situation is even more complicated, as they're "internally" RISC, and you can kind-a-sort-a treat them that way by staying away from the "heavy" instructions. That is if you can reason about what kind of time you're going to see from your micro-opped+out-of-order core anyway. The internals, and specifically the timing models have gotten even more complex than they already were. I don't know what your take on that would be?
And, given that most processors running GUI systems these days, and even most processors running GUI systems before x86/ARM ended up running most of the UI code people see, didn't have register windows, no, they're not needed. Yeah, SPARC workstations may have been popular, but I don't think register windows magically made GUIs work better on them. (And remember that register windows eventually spill, so once the stack depth gets beyond a certain point, I'm not sure they help; it's shallow call stacks, in which you can go up and down the call stack without spilling register windows, where they might help.)
I remember reading research back in the day, that showed that register windows were orthogonal to any RISC/CISC considerations, i.e. they were about as easy/costly to implement in either architecture and they gave the same boost/or not, in either case. As you point out, in practice it turned out to not be really worth the trouble, and they died out rather quickly.
Generally the ones who have problems are the "vocal minority": that is, if you have problems, you are more likely to speak up, so if you're only seeing 20 / 13million, it could well indicate that the problem is quite limited.
Sure, I'm one of those. I raised hell, on a Swedish electrical/electronics forum... Didn't even bother to call HP. I assumed it was a one off, and what are they going to do anyway? Tell me to send the cable to them? (That's too much of a hassle) and give me a new one? (I could just grab a new one from one of the conveniently situated piles at work).
In fact, the usual rule, born out by science, when it comes to customer satisfaction here in Sweden (originally talking about large enterprises like TV/Radio) is that for every complaint you have 4000 people who are dissatisfied but don't bother to make contact.
Now, of course, a recall could still be warranted even if there were only 20 out of 6 million, since there shouldn't be any at all. Compare the Challenger disaster. That the O-rings had only been eroded through a third of the way, didn't really mean that they had a safety factor of three, since they weren't supposed to erode at all! Likewise, these cables weren't supposed to melt either, and by a substantial safety margin at that. If as many as 20 do, that means that there is a systematic error somewhere.
With the limited info I have I would guess either a cheapskate manufacturer that tried to pass the wrong gauge of cable as the correct one or a crappy connection between a plug and the cable.
I have one of these cables and after having analysed it, we (the guys on the forum and I
In my own case, the cable finally conducted enough to trip the RDC on my house, and that's when I started investigating. Having confirmed the problem, I then remembered the time on the airplane across the Atlantic when my socket wouldn't stay on, or the time on the train when the whole side of my car kept switching off... I had inadvertently travelled the world, leaving darkness and despair in my wake...
Pictures of my measurements (and discussion, in Swedish I'm afraid). At 20mA, the cable developed 4.6W and my measured 80C (176F) is reasonable. I didn't really notice it before, since the powersupply gets quite warm as it is.
No, I think it's more that these people have always been here, but the last couple of years has seen a) the flourishing of the disgusting "Men's Rights" movement, b) more talk about sexism in the tech industry, which has lead to c) more articles about the subject here, and thus more arguments about it. In almost 15 years here I don't think the demographic has changed very much at all - there's a wider age range and it's more international, but fundamentally it's the same sort of audience. The site just has more articles on topics where this sort of thing comes up.
The rampant sexism seen in a lot of these articles is pretty depressing though.
Well put, I do seem to have noticed a sort of creeping Calvinism in the way that victims of all kinds of types are labelled today.
You have the same amount of "skin in the game", whether the man is driving a paying fare or giving a free ride to a friend.
No, frequency and other conditions are different. It's not an accident that you can bring your friends with you in your small aircraft with just an ordinary (sport) pilot license. If you want to take a paying passenger then you need a transport pilot license.
Same with boats.
Why are taxis different?
The wherewithal comes simply from experience --- not from a license.
And that's (drum roll) one of the conditions of a taxi (i.e. commerical) license in my country. Having sufficient experience that is. The license is there to (among other things) show that you have that experience.
And why must "higher level of skills" be a requirement â" even for the customers, who are perfectly satisfied with average level of skills?
Well, the customers are not the only ones with skin in the game. The rest of us have to share the roads with these "taxis" as well. The major reason that other commercial drivers (or air line pilots for that reason) isn't that they'll necessarily will kill their passengers, but that they will kill a bystander or other motorists. The rules for getting a bus driving license and a heavy truck driving license are the virtually the same, here in Sweden at least, and in one of those cases we're clearly not worried by the safety of the passengers.
It's the same at sea and in the air, if you want to transport paying passengers you have to show a higher level of competence. One reason mentioned in those cases is that you for example have to have the wherewithal to be able to stand up to a pissed off customer when you deem conditions to be unsafe, something that's more difficult (legally/financially) than when you have another passenger.
To be fair, that was a smaller problem in telecoms. We never change anything, in any way, if we can help it.
But I hear ya, and in the general case of course you're as right as can be.
And also something I came to value when working in industry and developing both cli and GUI admin tools for telecoms equipment:
You can easily document, email and (to a lesser extent) talk about a cli. A GUI not so much. When you've tried to walk someone through finding the hidden option in a GUI over the phone for the tenth time you're ready to tear your hair out. With a cli you can just email some commands and that's that. Documenting a GUI invariably devolved to a lot of screenshots which makes any workflow tens of pages long, instead of ten lines of commands which you then have ample space to explain and comment on. It's also much easier to read and follow along as you're e.g. installing, than leafing through screenshot after screenshot.
It verges on astounding. I've read for years that Germany has ceded sovereign control of its land to Russia for natural gas, and that German citizens would freeze by the tens of thousands if Putin turned off the taps.
And that's largely still true as a matter of fact. HOWEVER, Germany relies less on Putin's gas than Putin relies on Germany's money for that gas. (I.e. the value of Germany's gas imports as a part of their energy expenditure is small compared to the overall hard currency income that Putin receives from selling gas to Europe). Hence we're witnessing the situation with gas used as a weapon against the Ukraine and Belarus, but not against Germany.
That's not to say that it won't happen. Just that it takes more will on the Russian side than what they've been able to muster so far. Don't for a minute think that it doesn't factor in the decisions of Frau Merkel when it comes to sanctions against Russia for their part in the Ukraine debacle though. We would probably be tougher from the European side if it weren't for that gas...
Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall
