Talk:Don't-care term

Citation style

@Matthiaspaul: I'm disappointed with this edit after you had been reverted once. Yes, there was an inconsistency in style, but you chose to add citation templates when two out of the three citations did not use them. The third citation came with a merge from another article on an only tangentially related topic. So essentially the only references in this article directly on this topic were inserted by me with a different style. Calling on CITEVAR to justify your action is stretching it. SpinningSpark 08:56, 31 March 2020 (UTC)

Write-only memory

What is this connection to write-only memory supposed to be? I fail to see how that is "don't care" or how it helps minimisation. SpinningSpark 09:04, 31 March 2020 (UTC)

"Helps" would be misleading, it often is (or was) a consequence of the optimization process in order to save logic gates.

From the viewpoint of a programmer, read/write registers are typically much more convenient to deal with than write-only registers, but they require more logic gates to implement than found to be available in the design of older hardware (discrete logic, but also in many older peripheral controllers and microcontrollers) for size or costs reasons. Therefore, where it was non-essential, the read-functionality was often ditched in the optimization and moved into "don't care" territory - sometimes it partially survived the process (only some bits instead of whole registers, sometimes reliable only under certain conditions, something not reliable at all), but often left undocumented.

Given the abundance of available logic gates today, this is typically no longer a problem, so today registers are mostly read/write, except for in cases, where the desired functionality does not allow for this.

--Matthiaspaul (talk) 09:37, 31 March 2020 (UTC)

Even accepting that a register is designed with not read capability, that still doesn't explain why it's a don't care term. If the processor doesn't care what's in there, why is it bothering to write to it? Do you have a source describing such a design as "don't care"? SpinningSpark 12:24, 31 March 2020 (UTC)

That's why I wrote about registers, not mere memory cells. I don't know if you have a programming background, but back in the 1970s/1980s it was a major pain to write low-level software and device drivers for peripheral controllers. Even the controllers used in the IBM PC had a lot of registers which were write-only, so you never knew the state of the hardware, and either had to make assumptions (which often but not always worked) or reinitialize the hardware from scratch (reducing performance and flexibility). The linked-to article gives the UART controller as an example, but it also applied to the keyboard controller, interrupt controller and to most early graphics controllers (MDA, HGC, CGA, MCGA, EGA). The designers of these chips didn't do this out of "ignorance", but because they ran out of logic gates to implement the originally desired full functionality. That's why some of the states necessary for read/write functionality were declared "don't care" during development in order to reduce the number of necessary gates. Sometimes, parts of the originally intended read-functionality remained (but was only available with sideeffects on certain non-sensical conditions caused by the optimization), sometimes it was removed completely so that reading such a register gave unpredictable results - most often, whatever might have been left of read-functionality was not documented, leading to programmers to devise obscure tricks trying to find out about and possibly utilize such remaining functionality if this gave them some performance advantage. I vaguely remember designs where reading certain undocumented registers even caused the hardware to "lock up" completely until the next power-cycle, however, this was rare.

Back then, this was common knowledge among designers and I helped to documented some such undocumented chip behaviours, and also designed more than enough discrete hardware where I had to ditch read-functionality myself through don't cares.

So, write-only functionality of registers is (or was) often (although not necessarily - there are also a few cases, where this was as intended by the original design) an example of the result of don't care optimizations. That's why I put it into the See also section originally, but your removal forced me to put it into the article body.

--Matthiaspaul (talk) 18:15, 31 March 2020 (UTC)

A fictitious and easy-to-understand (although untypical) example could be an 8-bit register where the programmer can write a character into, which will then be printed by the line printer. It is write-only just from the programmer's point of view: it cannot be read back by the programmer, but of course the printer hardware does read it. - Jochen Burghardt (talk) 21:07, 31 March 2020 (UTC)

Matthias, to answer your question, I have some limited programming experience over my forty year career going back as far as the early 70s. But you are missing the point. You are wasting your time writing long screes trying to convince me that write-only registers exist. You don't need to do that, I believe you. What you are not convincing me of is that reliable sources exist calling these "don't care" terms. Less argument, more sources please. SpinningSpark 15:21, 1 April 2020 (UTC)

Nobody is "calling write-only registers 'don't care' terms", and I certainly didn't state this. However, write-only registers were (often, not always) a consequence of don't care optimizations. It is therefore a related topic in the scope of interest of people reading about don't cares, similar to your addition regarding power-up states. I did not intend to expand this into a section of its own, that's why I originally added it as a link to See Also only.

--Matthiaspaul (talk) 16:45, 1 April 2020 (UTC)

Still not seeing a source from you. Any material lacking a reliable source directly supporting it may be removed and should not be restored without an inline citation to a reliable source. SpinningSpark 17:58, 1 April 2020 (UTC)

I find Matthiaspaul's argument convincing, and hence suggest just to flag his sentence with {{cn}}, for now. Finding a source about a 40 year old issue may take some time, in particular nowadays when all libraries are shut down. - Jochen Burghardt (talk) 19:58, 1 April 2020 (UTC)

Origins of the terms "Don't care" and "Can't happen"

It might be interesting to determine the origin of the terms "don't care" and "can't happen". So far, I could not find a source earlier than Maurice Karnaugh's 1953 paper using the term "don't care" and the 1968/1969 article and book source by Noel Malcolm Morris using the term "can't happen", so it is possible that they coined these terms. In the 1950s, a variety of other terms was in use as well by various authors.

If you run into earlier publications using these terms, please add them to the article (or report them here). Thanks. --Matthiaspaul (talk) 11:05, 17 April 2021 (UTC)

ISBNs

@Matthiaspaul: In multiple references you have ended up with two ISBNs, one from the ISBN field and one from the ID field. Is this intentional, and if so why? SpinningSpark 11:02, 15 August 2021 (UTC)

Hi Colin. Yes, this is intentional. In most of these cases, the difference is just between the 10- and 13-digit ISBN formats. If there is only one ISBN (|isbn=) it should be the one actually printed on the publication. However, modern databases often only list the 13-digit equivalent codes. (I consider it a design flaw of the ISBN system that the longer codes are not supersets of the shorter ones, otherwise we wouldn't have this problem.) As a consequence, users of the book might search for a different code than users of those databases, and listing both ISBNs (the alternative form only via |id=) we can make sure that they both will find the citation when entering it into our search function.

The "Digital Logic Design" case is different: In this case the actual ISBN printed on the book does not adhere to the normal encoding scheme for ISBNs, so our citation templates would normally throw an error. However, valid or not, since it is printed on the book, it has been used, so we have to use it as well. In order to let our template accept it, we have to frame the code in our special ((accept-this-as-is)) syntax, which gets stripped off for display and metadata generation purposes. Since many databases will not allow such "valid invalid" ISBNs to be entered, the book has been assigned with a new ISBN later on. In order to make sure that users only knowing the new ISBN will still find the citation, we have to list it as a second ISBN (in this case via |id=).

--Matthiaspaul (talk) 11:09, 17 August 2021 (UTC)