Forgot your password?

Comment: Re:My opinion on the matter. (Score 1) 810

by Guy Harris (#47794125) Attached to: Choose Your Side On the Linux Divide

The whole "under 1024 is safe" is generally regarded for connecting *to* ports under 1024, not receiving connections from them.

It's only "safe" if you 1) trust that the machine to which you're connecting restricts the ability to bind to ports under 1024 (not guaranteed), and that the only people running processes on the machine in question are either trustworthy or are restricted from running programs that bind to those ports (not guaranteed), and that the system services you care about have ports under 1024 (not guaranteed).

And what guarantees that a "system service" (whatever that might mean) has a port under 1024? Perhaps a better scheme for determining whether to trust a service is called for here - one that would probably obviate the need for "privileged ports".

Yes, some services (NFS in particular) want to trust incoming connections from 1024 but they're in the minority.

One would hope that services that trust untrustworthy guarantees would be in the minority; in the best of all possible worlds, they would be completely non-existent.

If I was so inclined as to trust port numbers alone (and for the record, I don't trust incoming port numbers at all)

Good. Ideally, nobody would trust them, and claims such as "It prevents regular user programs from masquerading as system services, which usually sit below port 1024." would be treated as the uninteresting claims that they are.

Comment: Re:There's a lot more going on... (Score 1) 159

by Guy Harris (#47794031) Attached to: Research Shows RISC vs. CISC Doesn't Matter

The discussion was about adding more registers in a CISC architecture, and so CISC functionality is the context.

"CISC functionality" is the ability to execute a given CISC instruction set with acceptable performance. Transistors can be used in several different ways to achieve that, and you can choose to use fewer transistors in one place on a chip in favor of more transistors in another place, and if that choice means you still get better overall performance executing the same instruction set, that choice is a good one.

When you ask what "the same functionality means" that is absurd. You can't implement a subset of the functionality and still have the same functionality.

Again, as long as the full instruction set can be executed (even if some of it is executed by trap code), you don't have a subset. You may happen to execute some functions slower, and other functions faster, but if the net result is faster execution of the code actually run on the machine, you have a better implementation.

I'll put this in simpler terms. Smart people design CPUs and they don't add a bunch of registers even though that would be useful.

Smart people add registers iff they're sufficiently useful that it's worth either increasing the die size or taking transistors away from other functions.

The reason they don't do it is because of the additional chip real estate it would cost in an already over-taxed landscape, not because they are lazy or haven't though of the idea.

For existing architectures, the reason they don't do it is that it would require changes to the instruction format, which, for most instruction set architectures, would be a royal pain. For x86, they (AMD, to be specific) could and did add Yet Another Prefix to double the number of registers as the instruction set already had a tradition of adding prefixes. For ARM, they were already introducing a 64-bit variant of the instruction set, and didn't have to maintain binary compatibility. For, for example, System/3x0, you'd have to add prefixes to an instruction set lacking prefixes, or somehow use opcode bits to refer to additional registers. If somebody were to design a brand new CISC architecture (in an era where we're not designing many new instruction set architectures at all), they could design one with 32 GPRs.

Comment: Re:isn't x86 RISC by now? (Score 1) 159

by Guy Harris (#47789305) Attached to: Research Shows RISC vs. CISC Doesn't Matter

The AMD-64 architecture - is that also register limited?

With 16 GPRs, it has fewer registers than all the major RISC architectures other than 32-bit ARM, just as the 32-GPR System/3x0 (including its 64-bit z/Architecture version) does. It's less register-limited than x86, but that's not setting the bar very high. (Note that IBM recently added instructions to z/Architecture that do arithmetic on the upper 32 bits of the GPRs; that suggests that there's some register pressure with only 16 GPRs, although if they still have to make use of base registers, even with PC-relative branches, that might add some additional pressure that x86-64 doesn't have.)

Or did AMD toss something like 32-64 program accessible registers @ the problem?

No, they didn't; x86-64 has, as noted, only 16.

And if they did, would Intel have limited theirs?

Limited their what?

Comment: Re:ROLF! (Score 1) 213

by Guy Harris (#47785955) Attached to: Canada Tops List of Most Science-Literate Countries

Better than, say, the health care systems in the UK, Germany, France, Spain, the Netherlands, Switzerland, Taiwan, etc.?

there are a lot of shitty developing countries with healthcare that's much worse, and there's the united states.

There are a good number with better healthcare than Canada no question, but the number of countries with much worse or none eclipses that list

There's "the alternatives" and there's "the alternatives worth considering". The latter category excludes the developing countries in question, as well as the US. Hopefully the people in charge of health care in Canadian governments (federal and provincial) are looking at the alternatives in the latter category to see what they can learn from them.

Comment: Re:There's a lot more going on... (Score 1) 159

by Guy Harris (#47785389) Attached to: Research Shows RISC vs. CISC Doesn't Matter

No. That's correct. You can't add registers, keep the same functionality, and add all the circuitry to suport said functionality by reducing functionality and taking away regsiters. Who would have thought?

That isn't answering the question I asked.

The question I asked was "You can't trade off, say, transistors used for registers (especially given that the bigger processors do register renaming, so you have more hardware registers than the actual RISC/CISC instruction set provides) for transistors used for some other purpose?"

I said nothing about keeping all the same functionality, if by "functionality" you mean, for example, "on-chip caches of the same size" and "same number of hardware registers including ones used for renaming of the architected registers" or "complexity of the branch prediction hardware" or .... Yes, there may be tradeoffs you have to make in how you use your transistors, but if the benefits of the additional registers outweigh whatever performance benefits you lose by reducing the size of other functional units by however much the additional registers require, that might be the right tradeoff to make.

Comment: Re:There's a lot more going on... (Score 1) 159

by Guy Harris (#47782199) Attached to: Research Shows RISC vs. CISC Doesn't Matter

Whereas some CISC instructions involving arrays could kick off 10+ memory touches as a side effect ... That CISC operation that made 10 memory touches took roughly 10-18 bytes of instruction storage (68K example)

OK, that's probably using "memory indirect postindexed mode". Addressing modes that complex are something some CISC processors had, but not others; x86 is much less complex (scaling, but no memory-indirect or auto-increment/auto-decrement), and S/3x0 even less complex than that (no scaling, just double-indexing).

How often was that addressing mode used, in practice? Was it used often enough that you saved enough code space that you could make the I cache smaller?

Comment: Re:Is the anonymous reader aware of Europe? (Score 1) 213

by Guy Harris (#47782035) Attached to: Canada Tops List of Most Science-Literate Countries

I"m well aware of various European health care systems and also what is wrong here but I'm not most Canadians.

Then presumably, if the anonymous submitter was Canadian, they were one of "most Canadians", and offered his or her hypothesis about the attitudes towards science and the Canadian health care system because either 1) they didn't pay attention to the EU results or 2) they assumed that European countries are like the US in their heath care systems.

Or perhaps they were a typical Amurrican and made the same silly assumptions.

In any of those cases, if the second paragraph of their submission had been eaten by a grue, nothing of value would have been lost - heck, something would have been gained. (I mean, my knee-jerk reaction would have been to blame "We depend too much on science and not enough on faith" on Amurrican religiosity, but, absent any data on whether the more-religious countries in the EU have a sufficiently-high level of agreement with that assertion as to drag the EU average down, even with those countries in the EU that are less religious than Canada, I wouldn't wonder too hard about that one.)

Comment: Re:My opinion on the matter. (Score 1) 810

by Guy Harris (#47781889) Attached to: Choose Your Side On the Linux Divide

I'm not sure what you're trying to prove here

That if you think a packet coming from a privileged port is coming from a program run by a user whom you can trust, that's only true if you can trust everybody who's plugged a personal computer into your network or you can ensure that nobody on any of those computers gets to run programs with sufficient privileges to get to use privileged ports. (Remember that this subthread started with a mention of privileged ports, which I do not consider one of the Great Ideas In Network Security.)

When I gave this Connectathon talk, somebody asked about the

MacOSX automounter daemon
Launched in user’s session by launchd - exits when idle
Runs with user’s credentials

slide, with "ZOMG WHAT IF THE NFS SERVER ONLY SUPPORTS MOUNT REQUESTS FROM A PRIVILEGED PORT!!!!1111ONE!!!!", I forget what I said, but, in retrospect, I wish I'd said "oh, we're going to remove the root-only restriction on privileged ports", and taken delight in any pathetic squeals of terror that resulted.

(We ended up, for other reasons, running automountd as root in a privileged session, so that wasn't an issue.)

sudo won't let you run anything it's not configured to let your user or group run. If you're allowed to sudo as a non-admin user then either your system or your admin is broken.

Who's "you" in this context? I am an admin user on my Mac; if that means that plugging my machine into your network would terrify you, then you'd better somehow make sure that never happens. Don't expect me to care about your problem.

Comment: Re:Is the anonymous reader aware of Europe? (Score 1) 213

by Guy Harris (#47781771) Attached to: Canada Tops List of Most Science-Literate Countries

It's what we're most exposed

So? Most of us USans are mostly exposed to the US system as well, but that's not an excuse for being clueless about the rest of the world.

I.e., if "gee, our health care system doesn't let people who aren't well off get no health care" is offered as an explanation for why Canadians are less likely than people in the European Union to say that "We depend too much on science and not enough on faith.", whoever offers that explanation really needs to start looking at European health care systems, or, at least, to get a by-country breakdown of the EU figures and see whether there's any correlation between having a health care system that lets the poor fall through the cracks and believing that "We depend too much on science and not enough on faith."

(And if they weren't even bothering to care about countries other than the US when concocting that hypothesis, they need to get out more.)

Or, to put it another way, I refuse to give a damn whether it's what you're most exposed to, as it's completely irrational to care; if I were Canadian, I'd be embarrassed to see a fellow countryman acting as if the US was the only other significant country on the planet and as if the EU didn't exist.

Comment: Is the anonymous reader aware of Europe? (Score 4, Informative) 213

by Guy Harris (#47780393) Attached to: Canada Tops List of Most Science-Literate Countries

They say

I also wonder if the vaunted Canadian healthcare system plays a role. When advances in medical science are something you automatically expect to benefit from personally if you need them, they look a lot better than when you have to scramble just to cover your bills for what we have now.

but it sounds as if they're comparing the Canadian system for paying for health care with the US system, as opposed to the systems used in for example, Western Europe.

Comment: Re:There's a lot more going on... (Score 1) 159

by Guy Harris (#47779581) Attached to: Research Shows RISC vs. CISC Doesn't Matter

That's absolutely correct, unless of course you count the fact that you can't create a CISC CPU with just as many registers that can be used to store data, manipulate data, etc sans a cache hit as a RISC CPU given the same die size.

You can't? You can't trade off, say, transistors used for registers (especially given that the bigger processors do register renaming, so you have more hardware registers than the actual RISC/CISC instruction set provides) for transistors used for some other purpose?

Comment: Re:isn't x86 RISC by now? (Score 1) 159

by Guy Harris (#47779517) Attached to: Research Shows RISC vs. CISC Doesn't Matter

RISC processors had hundreds of registers to store the stack frames. There is some smart overlapping of stack frames so that functions could pass by reference straight through registers. When you look at the depth of the function call stacks in some GUI systems, those are needed.

RISC processors with the letters "S", "P", "A", "R", and "C" in the instruction set name, in that order, did. The ones with the digits "8", "0", "9", "6", and "0" in the processor name also did, I think. The ones with "M", "I", "P", and "S" in the instruction set name, in that order, did not, nor did the ones with "A", "l", "p", "h", and "a" in the instruction set name, in that order, nor the ones with "A", "R", and "M" in the instruction set name, in that order, nor the ones with instruction sets having names matching the regular expression "P(ower|OWER)(PC| ISA)".

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

Then there would be separate addition/multiplication and vector operation units, so that separate instructions could be processed independently. Modern CPU's are also deeply pipelined to around 14+ stages - every one of the classic four Fetch, Read, Execute, Write stages has been parallelized with pre-lookup, abort and bypass stages, so that means that around 100+ instructions can be in flight at any time. Then the results written back into registers have to be synchronized. So there are register scoreboards to keep track of dependencies. To keep track of all those and to guarantee program execution safety, extra instructions have been added to implement mutex's and thread barriers in hardware.

None of which has anything to do with RISC vs. CISC, and much of which wasn't the case when RISC processors first came out.

Another difference was that RISC CPU's would implement complex instructions like floating-point division in microcode rather than in hardware logic.

Actually, it's more likely to have been the other way around, unless by "microcode" you meant "software". These days, most processors whether RISC or CISC, probably do floating-point division in hardware.

Comment: Re:isn't x86 RISC by now? (Score 3, Informative) 159

by Guy Harris (#47778789) Attached to: Research Shows RISC vs. CISC Doesn't Matter

They're not the only ones. The IBM mainframes have long been VMs implemented on top of various microcode platforms.

But the microcode implemented part or all of an interpreter for the machine code; the instructions weren't translated into directly-executed microcode. (And the System/360 Model 75 did it all in hardware, with no microcode).

And the "instruction set" for the microcode was often rather close to the hardware, with extremely little in the way of "instruction decoding" of microinstructions, although I think some lower-end machines might have had microinstructions that didn't look too different from a regular instruction set. (Some might have been IBM 801s.)

So that's not exactly the same thing as what the Pentium Pro and successors, the Nx586, and the AMD K5 and successors, do.

Currently mainframe processors, however, as far as I know 1) execute most instructions directly in hardware, 2) do so by translating them into micro-ops the same way current x86 processors do, and 3) trap some instructions to "millicode", which is z/Architecture machine code with some processor-dependent special instructions and access to processor-dependent special registers (and, yes, I can hear the word PALcode being shouted in the background...). See, for example, " A high-frequency custom CMOS S/390 microprocessor" (paywalled, but the abstract is free at that link, and mentions millicode) and "IBM zEnterprise 196 microprocessor and cache subsystem" (non-paywalled copy; mentions microoperations). I'm not sure those processors have any of what would normally be thought of as "microcode".

The midrange System/38 and older ("CISC") AS/400 machines also had an S/360-ish instruction set implemented in microcode. The compilers, however, generated code for an extremely CISCy processor - but that code wasn't interpreted, it was translated into the native instruction set by low-level OS code and executed.

For legal reasons, the people who wrote the low-level OS code (compiled into the native instruction set) worked for a hardware manager and wrote what was called "vertical microcode" (the microcode that implemented the native instruction set was called "horizontal microcode"). That way, IBM wouldn't have to provide that code to competitors, the way they had to make the IBM mainframe OSes available to plug-compatible manufacturers, as it's not software, it's internal microcode. See "Inside the AS/400" by one of the architects of S/38 and AS/400.

Current ("RISC") AS/400s^WeServer iSeries^W^WSystem i^WIBM Power Systems running IBM i are similar, but the internal machine language is PowerPC^WPower ISA (with some extensions such as tag bits and decimal-arithmetic assists, present, I think, in recent POWER microprocessors but not documented) rather than the old "IMPI" 360-ish instruction set.

The main differences between RISC and CISC, as I recall were lots of registers and the simplicity of the instruction set. Both the Intel and zSeries CISC instruction sets have lots of registers, though.

Depends on which version of the instruction set and your definition of "lots".

32-bit x86 had 8 registers (many x86 processors used register renaming, but they still had only 8 programmer-visible registers, and not all were as general as one might like), and they only went to 16 registers in x86-64. System/360 had 16 general-purpose registers (much more regular than x86, but that's not setting the bar all that high :-)), and that continues to z/Architecture, although the latest z/Architecture lets you do arithmetic separately on the upper 32 bits and lower 32 bits of a GPR, so for 32-bit and shorter arithmetic, you sort-of have 32 GPRs. z/Architecture also boosts the number of floating-point registers from 4 to 16.

Most RISC instruction sets had 31 or 32 GPRs (in the 31-GPR machines, one of them was always zero when fetched, and operations writing into it discarded the result); ARM had only 16 (one of which was the PC, so not really usable), but 64-bit ARM has 32.

So the main difference between RISC and CISC would be that you could - in theory - optimize "between" the CISC instructions if you coded RISC instead.

As I see it, differences between current RISC and CISC instruction sets are:

  1. RISC ISAs are load/store, meaning that arithmetic instructions are all register-to-register, whereas CISC ISAs have memory-to-register arithmetic. Splitting memory-to-register arithmetic does let you optimize "between" the memory reference and the arithmetic. However, breaking a memory-to-register arithmetic instruction into separate memory-reference and arithmetic microops lets the hardware do similar things.
  2. RISC ISAs generally have more registers; that's not an inherent RISC vs. CISC characteristic, however. A CISC ISA could have, for example, 32 GPRs; at the time S/360 was designed. you couldn't just throw transistors at the problem, and, on the lower end S/360's, the GPRs were stored in a small higher-speed core memory array, not in transistorized registers, and they may have thought that assembler-language programmers and compiler writers wouldn't have been able to make much use of 32 GPRs in any case.
  3. 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.

Presumably somebody tried this, but didn't get benefits worth shouting about.

Actually, I think many compilers for RISC processors will schedule instructions in that fashion. Of course, modern RISC processors may reschedule instructions in hardware, just as modern CISC processors may reschedule microoperations in hardware ("out-of-order" processors).

Incidentally, the CISC instruction set of the more recent IBM z machines includes entire C stdlib functions such as strcpy in a single machine-language instruction.

...which is probably implemented as a fast trap to a millicode subroutine in the aforementioned z/Architecture-with-its-own-private-GPR-set-plus-maybe-some-processor-dependent-instructions machine language. The millicode routine doesn't, as far as I know, have to save or restore any GPRs, as it gets to use its own set, and probably runs from memory that's as fast as the level 1 instruction cache rather than from the I-cache, so it might reduce I-cache misses, and can transparently differ from processor to processor in case the best string-copy or string-translate or... instruction sequence differs from processor to processor. Of course, a RISC processor could add "fast call" and "fast return" instructions that do similar GPR-set switching, and have a bigger I-cache, and the OS could make processor-specific string copy routines available, so I don't know how much those instructions would buy you.

Pound for pound, the amoeba is the most vicious animal on earth.