Talk:NEC V60

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

V60 rumors[edit]

The comment about the Sega Saturn should be removed because it is irrelevant and incorrect:

1. There is no evidence Sega used Model 1 as a reference for the Saturn. The Saturn architecture is entirely unlike Model 1 and bears absolutely no resemblance to it.

2. There is no evidence Sega planned to use a V60 in the Saturn. While the Saturn video hardware is a predecessor for the System 32 video hardware, the rest of the design is highly SH-2 centric (specifically the SH-2 specific SCU and a system memory architecture closely tied to the SH-2 feature set).

The comment is speculative and offers no proof to back up these claims.

130.65.11.98 (talk) —Preceding undated comment added 05:18, 2 March 2010 (UTC).[reply]

  • I don't know enough about Sega stuff to say if that's true or not. However everything else that was claimed about actual use in consoles checks out from the MAME comments on their source code (they have ASCII drawings of the stuff emulated in most C files.) So, this might possibly be true as well; I've tagged it with [citation needed] Someone not using his real name (talk) 19:26, 14 February 2014 (UTC)[reply]
  • I'm guessing whoever wrote that based it on info like [1], which says "While the Saturn was originally conceived to deliver performance similar to Model 1, the 16Mhz NEC v60 CPU relied on specialized support chips, and using such chips was not economical for a home console. Instead, the far more powerful Hitatchi SH2 processors were utilized." Which is less far fetched. Someone not using his real name (talk) 19:29, 14 February 2014 (UTC)[reply]
  • Another source [2] says "The Saturn originally ran on a NEC V60 chip at 16MHz. Compare this to the Playstation CPU (R3000A 32bit RISC chip) which runs are 33.8MHz, almost double the speed. According to one Sega staff member, when Nakayama first received design specifications for the Playstation, he was ‘the maddest I have ever seen him’, calling up the entire R&D division to his office to shout at them. An effort was made to compensate by adding another CPU for dual operation; however, this solution made the system so hard to develop for that, according to Yu Suzuki himself, “only 1 out of 100 programmers could use the Saturn to its full potential”." This seems to confirm the initial Saturn plans. Someone not using his real name (talk) 19:33, 14 February 2014 (UTC)[reply]

Old EE Times article on the V80[edit]

It was probably just an announcement but [3] mentions "There was an article about the V80 in the February 13, 1989 issue of EE Times." EE Times on-line archives don't go back that far though, so it's print only. Someone not using his real name (talk) 18:58, 14 February 2014 (UTC)[reply]

More in-depth source on the space-spec V70[edit]

There's an article in English in a French book/proceedings [4]; it's pretty obscure though obtainable through interlibrary loan in the US. The 2011 paper is unfortunately mostly focused on V70's replacement... Someone not using his real name (talk) 23:10, 14 February 2014 (UTC)[reply]

Need to maintain[edit]

This structured link description is removed from the article. Instead of it, some descriptions need to be added in the article itself. Some general descriptions might be suitable for locating in other computer architecture related articles.Cafeduke (talk) 02:52, 4 March 2018 (UTC)[reply]

"== See also =="

The section about RX-UX 832 needs some clarification[edit]

In NEC V60#Unix (non-real-time and real-time), it says:

NEC also developed a variant for V60/V70/V80, with a focus on a real-time operation, called Real-time UNIX RX-UX 832. It has a double-layered kernel structure, and all the kernel calls of Unix issues tasks to the real-time kernel.

Before the recent copy-editing, it said

NEC also developed a variant for V60/V70/V80 with a focus on a real-time operation called Real-time UNIX RX-UX 832. It has double layered kernel structure, and all the kernel call of Unix issues task to the real-time kernel.

but neither is clear.

The "Real-Time UNIX Operating System: RX-UX 832" paper cited as a reference doesn't say very much about the structure of the OS. A diagram shows a box labeled "The V60/V70 RTOS", with, inside that box:

  • a box labeled "The Real-Time Kernel";
  • two other boxes inside it, overlapping (but not contained within) "The Real-Time Kernel", one labeled "Unix supervisor" and one labeled "File System";
  • a box labeled "Unix interface", with an arrow going to "Unix supervisor" and an arrow from outside "The V60/V70 RTOS" going to it;
  • a box labeled "Real-time interface", with an arrow going to "The Real-Time Kernel" and an arrow from outside "The V60/V70 RTOS" going to it;
  • a box labeled "File System interface", with an arrow going to "File System" and an arrow from outside "The V60/V70 RTOS" going to it.

Outside, and above, the "The V60/V70 RTOS" box are two sets of other boxes:

  • a set of boxes, the topmost of which is labeled "Unix task", with arrows going from that set of boxes to "Unix interface", "Real-time interface", and "File system interface";
  • a set of boxes, the topmost of which is labeled "Real-time task", with arrows going from that set of boxes to "Real-time interface" and "File system interface".

They describe the OS as being built with the "building block approach". The paragraphs under "building block approach" say that

A virtual memory management mechanism for UNIX specific demand paging and a UNIX user-interface are maintained by a Unix supervisor. On the other hand, simpler and time-dependent functions, a memory management mechanism for real address spaces and common capabilities, such as a task scheduling, are provided by a real time operating system.

They don't indicate whether the arrows that go from "Unix task"s into the "The V60/V70 RTOS" box represent straightforward system calls, message-passing calls, or some other form of control transfer. The fact that there are arrows going from "Unix task"s to the "File Systems" box suggests that not all UNIX APIs that are traditionally implemented as "system calls" are implemented as transfers of control to the Unix supervisor.

"Task" can either be used in the conventional sense of a job to perform or in the technical sense that's similar to process. In "all the kernel call of Unix issues task to the real-time kernel", it sounds as if it might be used in the first sense, although, from the diagram, some calls from "Unix task"s to "The V60/V70 RTOS" don't go through the "Real-time interface" directly to "The Real-Time Kernel" - some go either to "Unix supervisor" or "File System".

If anybody has a reference giving more details, that would be useful. Guy Harris (talk) 08:20, 21 May 2020 (UTC)[reply]

You seem to have access to the paper that I can only see an abstract of. Consulting another resource, an old book on operating system elements that doesn't speak of "kernel" per se, I see that maintaining a real-time OS is basically a matter of scheduling, giving priority to those processes needing service in real time. I don't know how the process that governs that has a "double layered [...] structure". Perhaps that refers to scheduling priorities (realtime vs. interactive, say) and the splitting of the system according to such needs. In any case, I see a grammatical error or two in the sentence quoted from the article. I might try to fix that first. Dhtwiki (talk) 03:26, 22 May 2020 (UTC)[reply]
It's purchasable by following the link, signing up for an Elsevier account and, at least in my case, by copying and pasting a "Download PDF" link from Safari into Chrome, because Stuff Just Doesn't Work on their sites with either Safari or Chrome, for reasons not obvious to me (other than "the Web sucks, browsers suck, Javascript sucks, Web site software developers suck, everything sucks"). However, the problem is that the paper has little in the way of low-level details, so you don't get much, other than the pictures, by buying the paper. Guy Harris (talk) 04:05, 22 May 2020 (UTC)[reply]
@Guy Harris: Sorry you were disappointed by the reference paper, especially if the cost was in line with Elsevier's reputation for extortionate pricing. However, I think what you provided above is enough to amend the article to read:

NEC developed a variant that focuses on real-time operation, to run on V60/V70/V80. Called Real-time UNIX RX-UX 832, it has a double-layered kernel structure, with all task scheduling handled by the real-time kernel.

I haven't found much more on real-time operations, other than its use is generally neglected by Unix users, who usually find the niceness attribute sufficient. Dhtwiki (talk) 23:45, 27 May 2020 (UTC)[reply]

Archive links[edit]

@Dhtwiki: Regarding this revert: Some of the links in citations needed archive links because they are reported as live even though the cited content has been removed. (For example: http://www.chipcatalog.com/NEC/MV-4000.htm) It's useful to have the archive links there in any case, since live pages could disappear at any time, which would leave readers unable to verify or read more detail. -- Beland (talk) 19:47, 23 December 2021 (UTC)[reply]

Links suddenly going dead or being moved probably doesn't apply to the Google Books links, of which I spotted at least two. If it were obvious that you were only adding the archive links that you've checked for such need as you've described and for the reference's relevance in supporting article text, I wouldn't be reverting. Just running a bot that is apt to add unnecessary links, with the user not checking, adds clutter that gets in the way of my editing in raw editing mode and probably doesn't help as much as you might think. Dhtwiki (talk) 08:19, 24 December 2021 (UTC)[reply]
@Dhtwiki: I've certainly encountered broken Google Books links; I'm not sure Google has designed the service as a stable citation target. I would consider all the archive URLs necessary to avoid readers hitting dead links or sources that no longer support the claims in the article. I don't see how the additional parameters are cluttering the article for editing purposes, as in this article, all of that is in the References section and not the main article text. I would expect the most common reason to edit a citation is to fix a dead link, which is exactly what the archive data is there to help with. -- Beland (talk) 07:55, 3 January 2022 (UTC)[reply]
I've encountered Google Books links that don't lead to the text that supports what's in the article. That makes them rather useless, whether live or dead. I'm assuming that you're not really checking what each link leads to. If the links are marked as "live", are the archive snapshots even available for readers to click on if they find the original is dead? You're right about the list-defined references being less a problem in terms of "clutter", but usually references are more inextricably combined with text. I can work around clutter with a parser, such as wikEd; but seeing >11k of what I consider useless additions is still irritating (I wouldn't mind smaller byte counts, especially one referenced edited at a time, which would indicate that the editor adding them is actually checking). Dhtwiki (talk) 18:11, 3 January 2022 (UTC)[reply]
@Dhtwiki: Yes, status=live vs. status=dead simply changes the presentation a little, I assume to try to make it easier for readers to click on the correct link first. The problem of links going dead can be solved quickly and in an automated fashion. The problem of text drifting so that it no longer matches its citations requires a lot of manual editor time to fix. I don't think solving the first problem should require fixing the second at the same time; there's nothing wrong with incremental improvements on the way to perfection. Personally, if I'm investigating a problem with a citation and discover that it's a dead link, I just run the tool so I don't have to spend time manually constructing the archive.org citation. The bot can do it in a few seconds, and it can fix the whole page in a few minutes while I'm doing something else. Then I come back and click on the new archive link and resolve the actual problem (often a bad title). (That is in fact what I was doing in this case.) I don't think large diffs are a reason to fix problems more slowly; the faster we can improve the content, the better. I agree it would be nice if the archived-link syntax was less bulky. For archive.org links, it would actually be possible to get rid of the archive-url parameter, since it's predictably constructable by combining the archive-date and url parameters. Would it be worthwhile to draft a short-form template that does that? That would only leave the relatively short archive-date and url-status parameters. -- Beland (talk) 04:31, 16 January 2022 (UTC)[reply]
I don't think that supplying links to archive snapshots automatically solves much. If text drifts so that the reference doesn't support it, what is the point of maintaining the reference? So, yes, that should be checked at the same time. If you find a dead link where the reference is still relevant and linking to an archive snapshot is appropriate, and the automated tool makes it easier for you to insert the snapshot into the citation, then by all means use it. But that doesn't mean that it's helpful to supply snapshot links for all the citations. IABot doesn't do that when it checks articles on its own. It doesn't link to archive snapshots if it determines that the original link is live. There's also the matter of its being preferable to search for another direct link, due to dead links often being the result of website reorganization. The relevant page still exists but in a different place. Especially if it contains information (e.g. census data, lists of city or school officials, etc.) that is often changed, extra effort should be made to link to it, rather than rely on an out-of-date version. Dhtwiki (talk) 00:13, 17 January 2022 (UTC)[reply]
@Dhtwiki: As far as I know, there is no way to have the bot add archive links for specific links on a page, as opposed to all of them or all the links it thinks are dead. In this case, and most of the ones I'm fixing, IABot has incorrectly determined that a link is live, for example when it gets an HTTP 200 response but the page says "content not found" (which should be an HTTP 404 response). The point of adding an archive link to a citation that has gotten out of sync with the text is to make it easier for a human editor to determine that they has gotten out of sync, and to fix it. When I fix dead links manually, I usually just add whichever archive.org snapshot is the most recent. IABot does a better job picking the snapshot that's closest to when the citation was added to the article. And if I haven't been reading the article, I usually don't bother checking that it supports what the text is saying. If the citation needs an earlier snapshot, I figure I've just made it easier for some other editor to notice and fix that, since they can now just click around to find the right snapshot.
For "External links" sections, I certainly agree linking only to live sites is useful in most cases, and if I find a dead link there I will either just drop the link or search for a relocated live version if it seems worthwhile. For citations, it seems clear to me that linking only to a frequently-updated page is considerably worse. If an article claims the population of a city is 25,621, it does not verify the claim to provide a link to a page that now has the 2021 population when the claim was added to the article in 2016. (Obviously the article should also give the as-of date for highly dynamic figures like this.) When archive-url is supplied, both the live and archived version are supplied, so editors can click the archived version for verification purposes, and the live link to check for updates. -- Beland (talk) 04:52, 17 January 2022 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:NEC_V60&oldid=1209848632"