User talk:Guy Harris/Archives/2017/04

See Also

I was always under the impression that "See Also" was for other articles that may be of interest to the reader, but not specifically mentioned in the article? It's not to cover every permutation, so just because MIPS is not covered does not exclude ARM architecture. You're essentially referring to WP:OTHERSTUFF there. The exclusion of one subject does not exclude others. The reason I chose to include ARM is because I happen to know about about it, ergo was interested in other topics - the exact reason "See Also" exists. What is your reasoning to exclude ARM? My reasoning to include is similarity of topic. Chaheel Riens (talk) 17:43, 16 March 2017 (UTC)

@Chaheel Riens: My reasoning is stated in my edit comments. Just because they happen to be two instruction sets that one editor happens to know about, that doesn't mean that one of them happens to be relevant enough to the other one to be worthy of listing in "See also" in the other one's page. There are a lot of instruction sets, and even a lot of RISC instruction sets; the "See also" section shouldn't degenerate into a short version of List of instruction sets. Guy Harris (talk) 17:51, 16 March 2017 (UTC)

Well, according to MOS See Also, one of the accepted inclusion rationales is "Links to related topics – topics similar to that discussed in the article." So, because they happen to be two RISC instruction sets does mean that it qualifies for entry. It also states "When deciding what articles and lists of articles to append to any given entry, it is useful to try to put yourself inside the mind of readers: Ask yourself where would a reader likely want to go after reading the article" - based on that criteria, adding ARM architecture - and indeed MIPS as well, seems in line with MOS. My argument for inclusion is topic similarity, your argument for removal seems to be that you don't like it - or that it didn't include MIPS, ergo it shouldn't include Arm either.

Another section of the MOS states "The links in the "See also" section might be only indirectly related to the topic of the article because one purpose of "See also" links is to enable readers to explore tangentially related topics" It makes no mention of your Other stuff - that is exclusion of one subject demands exclusion of others - argument. Having thought about it, I reckon that MIPS maybe does have a place in the See Also of both articles. I had forgotten that MIPS was the basis of the StrongArm that found its way into the Acorn Risc machines. Chaheel Riens (talk) 18:23, 16 March 2017 (UTC)

@Chaheel Riens: "Ask yourself where would a reader likely want to go after reading the article" - based on that criteria, adding ARM architecture - and indeed MIPS as well, seems in line with MOS." And, based on that criteria, I could see it as being not likely; about all it has in common with PowerPC is that it's RISC and larger than 16-bit, but it has no historical/developmental connection with PowerPC at all - the ISAs that have such a connection are the IBM POWER Instruction Set Architecture, of which it's a mostly-binary-compatible derivative, and the IBM 801 which gave rise to various of IBM's RISC projects.

"My argument for inclusion is topic similarity, your argument for removal seems to be that you don't like it - or that it didn't include MIPS, ergo it shouldn't include Arm either." Please don't presume what my arguments are. My argument is that the only connection between PowerPC and either MIPS or ARM or SPARC or PA-RISC or... is that they're RISC and they started out as 32-bit. Not really that much of a connection, given that there are a number of ways in which they differ.

"I had forgotten that MIPS was the basis of the StrongArm that found its way into the Acorn Risc machines." What was used in the Acorn RISC Machines was the ARM instruction set architecture not at all based on MIPS or PowerPC or SPARC or any other RISC architecture. StrongARM was an implementation of the ARM instruction set, developed by Digital, and not used in any of Acorn's machines. Guy Harris (talk) 06:11, 17 March 2017 (UTC)

"StrongARM was an implementation of the ARM instruction set, developed by Digital, and not used in any of Acorn's machines" - would you like an opportunity to clarify that statement? 'Cause it's wrong. The SA-110 was used in the RiscPC - an Acorn machine, and one that I owned for many a year. Chaheel Riens (talk) 08:15, 17 March 2017 (UTC)

@Chaheel Riens: OK, I'll correct the statement; the corrected version is "StrongARM was an implementation of the ARM instruction set, developed by Digital", without the "not used in any of Acorn's machines". The claim that "MIPS was the basis of the StrongArm", however, also needs clarification, given that:

1) "MIPS" either refers to the Stanford Microprocessor without Interlocking Pipeline Stages, a word-addressable microprocessor developed as a research project at Stanford, or to the MIPS instruction set, which wasn't a microprocessor at all, it was an instruction set (or family of instruction sets, as new capabilities were added), with several implementations with names such as "R2000", "R3000", etc.;

2) StrongARM refers to a family of microprocessors that implemented the ARMv4 instruction set;

3) the MIPS instruction set was developed in the mid 1980's by MIPS Technologies;

4) the original ARM instruction set was developed in the early to mind 1980's by Acorn ("the originalARM instruction set " meaning "the instruction set from ARM that's not Thumb/Thumb-2/T32 and not A64");

5) the two instruction sets differ significantly, and I see nothing to indicate that the MIPS instruction set was the basis of the ARM instruction set in any way;

6) I also see nothing to indicate that the Microprocessor without Interlocking Pipeline Stages was the basis of any of the StrongARM microprocessors;

so in what way was MIPS "the basis of the StrongArm"? Guy Harris (talk) 08:41, 17 March 2017 (UTC)

From a design and team point of view - as you say "StrongARM was an implementation of the ARM instruction set, developed by Digital". Without MIPS there wouldn't be StrongARM - although I concede you could also say that with that argument almost all designs and architectures are reliant upon each other. Still - all this interesting discourse is a result of See Also, and we're both learning things. Chaheel Riens (talk) 09:10, 17 March 2017 (UTC)

@Chaheel Riens: The connection between MIPS and Digital is that Digital used MIPS processors in their DECstation line of RISC workstations. DEC didn't design the MIPS instruction set or the MIPS processors; those were designed by MIPS Technologies. They also didn't design the ARM instruction set; they entered into a joint project with ARM to develop the StrongARM chip. Were any of the people who worked on StrongARM connected either with MIPS Technologies, or with the group who worked on the MIPS workstations at DEC, before the worked on StrongARM? If not, then about the only team connection is that some of the people who worked on StrongARM later worked on MIPS processor designs at SiByte and Alchemy Semiconductor, according to the StrongARM page.

As for a design point of view, are you saying that the StrongARM CPU design was based on the CPU design of some MIPS processor? If so, which one?

Perhaps "without MIPS there wouldn't be StrongARM", but, unless you're talking about a chain of requirements such as "without RISC there wouldn't have been ARM" (true, given what the "R" in "ARM" stands for) and "without MIPS there wouldn't have been RISC" (although there's also Berkeley RISC -> SPARC - Sophie Wilson indicated that Berkeley RISC was something the ARM people looked at - as well as IBM's 801 project that gave rise to both ROMP and POWER) and "without ARM there wouldn't have been StrongARM" (pretty much self-evident), or you're saying there was a flow of ideas or designers from some people connected with MIPS to the StrongARM team, that would presumably be for business reasons, such as "without MIPS DEC wouldn't have had a strong enough business to work on StrongARM", rather than for technical reasons. Guy Harris (talk) 10:00, 17 March 2017 (UTC)

This is all genuinely interesting, but also away from the point of "See Also" that "See Also" can contain links to article "that may be of interest to the reader" - not will, but may - in this case it interests me, but not you. That seems to fulfill the "may" criteria. Chaheel Riens (talk) 13:39, 21 March 2017 (UTC)

"also away from the point of "See Also"" So why did you bring it up?

Unless there's some significant connection between the two instruction sets, you might as well just put Reduced instruction set computing in "See also" if the only connection is that they're both RISC, or List of instruction sets if they're not both RISC - and you've failed to show any evidence for a real connection between ARM and PowerPC, so the only connection I see is "they're both RISC". DEC Prism and DEC Alpha, for example, have a connection other than "they're both RISC", but ARM and PowerPC don't appear to. Guy Harris (talk) 17:01, 21 March 2017 (UTC)

Guy I left a comment for you on PAE talk page. I'm with you on "paging virtual memory". My bad for snapping also. Just a kneejerk reaction after fending of a few attacks recently. :)PastieFace (talk) 17:56, 13 April 2017 (UTC)

Please do not confuse IA-32 with x86

https://en.wikipedia.org/w/index.php?title=Physical_Address_Extension&type=revision&diff=775611502&oldid=775607135

As the above, your efforts would not be confirmed this time, for you confuse IA-32 with x86. IA-32 is an architecture, developed by Intel. So it lacks the support of some extensional instruction sets from other vendors such as MMX+, 3DNow!, 3DNow Professional and so forth, but those instruction sets build up the 32-bit architecture, which AMD64 was built on when AMD Athlon 64 and Opteron debuted. AMD name their IA-32 compatible processors as x86 processors, and naming that architecture with ambiguous term, x86. x86 is not official name for an architecture, but is used to referred to those similar and related things. It is quite like the word Jews. — Preceding unsigned comment added by 221.9.13.240 (talk) 02:00, 16 April 2017 (UTC)

Teletype

Thanks for the follow-on work! Jeh (talk) 04:16, 26 April 2017 (UTC)

Thanks for your fixes to device file

That's what I always hope for, that someone more authoritative will come along and clean-up after my well-intentioned guesses. I mainly edit Wikipedia when I'm scouting material where I don't yet know the precise dividing lines. And yet, I still attempt to fill holes in passing.

That udev is now managed by systemd is not irrelevant to the complexities inherent in device file systems, were that to become a separate article. — MaxEnt 19:36, 28 April 2017 (UTC)