Talk:Tomasulo's algorithm

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
???	This article has not yet received a rating on the project's importance scale.
	This article is supported by Computer hardware task force.

Imprecise exceptions

The claim in the article that imprecise exceptions cannot occur except in Out-Of-Order machines is wrong: in an in-order pipelined, single or superscalar machine there may be multiple simultaneous exceptions. Not every exception is detected at the same pipeline stage, and some late exceptions like bus errors may be detected only after subsequent instructions have completed. Where certain instructions are dispatched to a coprocessor, as in 80287 or MC68881, they may signal exceptions asynchronously! — Preceding unsigned comment added by 173.48.253.79 (talk) 11:05, 28 March 2015 (UTC)[reply]

I see that after 8 years, there has been no correction to this obvious mistake. I added a Disputed Section header. A reference that establishes the (well-known) fact that Tomasulo's original algorithm did not offer precise exceptions is "Implementing Precise Interrupts in Pipelined Processors", Smith and Pleszkun, available at https://www.cs.virginia.edu/~evans/greatworks/smith.pdf, which states: "The precise interrupt problem is as old as the first pipelined computers [5]. The IBM 360/91 [3] was a well-known computer that produced imprecise interrupts under some circumstances, floating point exceptions, for example. Imprecise interrupts were a break with the IBM 360 architecture which made them even more noticeable." There are many other references. This isn't a triviality; the problem of providing precise exceptions is fundamental to the design of computers with out-of-order execution. The person who wrote this erroneous content was probably confusing Tomasulo's original work with later work that addressed this (serious) issue. Can we just remove the section? It would be better to say nothing that to say something that's totally wrong. — Preceding unsigned comment added by 2601:1C0:5401:2040:5525:CCDC:6524:B9CF (talk) 03:34, 21 December 2023 (UTC)[reply]

It has been usual, for many many years, for processors that are otherwise in-order, to overlap fetch, decode, and execute. I suspect that can lead to imprecise interrupts. S/360 processors other than the 91 could generate a smaller number of imprecise interrupts. Early S/370, such as the 165, also did that. But for virtual storage to work, segment and page faults need to be precise! Gah4 (talk) 13:45, 1 December 2025 (UTC)[reply]

Floating-point?

Floating-point registers are mentioned twice, with no clear reason given.
Are they harder to schedule or dispatch in common architectures? Musaran (talk) 20:26, 14 November 2023 (UTC)[reply]

No. Floating point registers are mentioned specifically because Tomasulo's original design applied only to the floating point section of the CPU in the IBM 360/91. Tomasulo's 1967 paper described that design, so it uses "floating point register" to mean "register". If this article is to be improved, one of the questions that would have to be answered is whether the improved article is about the paper Tomasulo wrote or about the nature of algorithm (which is not specific to floating point registers). 2601:1C0:5401:2040:B043:CD70:FFCC:DE5D (talk) 23:39, 23 December 2023 (UTC)[reply]

The 360/91 was designed to speed up floating point. But an additional problem that would arise soon, is that S/360 has 16 general purpose registers, and 4 floating point registers. OoO for S/360 pretty much requires register renaming, otherwise you run out of them. (Many years later, I believe ESA/390 years, that was increased to 16.) But it is usual for floating point to take more cycles, and so mihgt be harder to schedule or dispatch in pipelined processors. Gah4 (talk) 13:40, 1 December 2025 (UTC)[reply]

"Tomasulo" listed at Redirects for discussion

The redirect Tomasulo has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2025 July 25 § Tomasulo until a consensus is reached. Dennis C. Abrams (talk) 12:04, 25 July 2025 (UTC)[reply]

S0C0

A dreaded, and way too common, result on the 360/91 is the system code 0C0 exception: multiple imprecise interrupt. Before an interrupt, the pipeline has to be flushed, and additional exceptions can occur. Those are indicated with bits in the OPSW, but as always, one does not know the location of the instruction. The PL/I (F) compiler has an option to keep track of the statement being executed, to help users. On the 360/91, it changes the message to NEAR STATMEMENT ... Should muliple imprecise interrupts be discussed in the article? Gah4 (talk) 13:50, 1 December 2025 (UTC)[reply]