Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: I vote NO on motion 21...



Am 05.12.2010 04:15, schrieb Dan Zuras Intervals:
	Folks,

	I vote NO on motion 21.

	My reason has nothing to do with the set of
	comparisons proposed.  Any reasonable set is
	fine with me.

	The reason I vote NO is that the motion is
	written in a manner that suggests (or even
	implies) the existence of state attached to
	the act of making a comparison.

	We wrote comparisons in a similar manner in
	754-1985&  it led to implementers actually
	CREATING such state as 4 global variable
	bits usually in a PSW attached to the thread
	of execution in question.

	At the time&  in the era of 4 MegaHz 8-bit
	microprocessors that implemented their
	floating-point in software more often than
	not, this was not considered bad.

	But in the years that have followed it has
	become clear that requiring state is a bad
	thing in the era of multi threaded multi
	GigaHz 32 or 64 bit microprocessors with
	multiple on chip floating-point units.  It
	creates an interlock choke point similar to
	a branch that slows everything down&  makes
	added headaches for the hardware designer.

	And, for us, it will delay the acceptance
	of 1788 into general hardware use.

	But all is not lost.

	It would be sufficient to rewrite motion 21
	to describe the list of comparisons only.

	Any organization of those comparisons into a
	system that requires 13 states to describe it
	(such as tables 1&  2&  the language that goes
	with them) should be left out or, at the very
	least, relegated to an informative annex.

	If this were done I would change my vote to
	YES.

	Yours,

			   Dan


Dear Dan, P1788,

as you can see in the motion text there is no requirement for global state.

>>>>
Motion 21
"P1788 should provide access to the states of the interval overlapping
relation. In particular it should provide a function on two intervals a and b whose range is the set of 13 states defined by tables 1 and 2. Additionally the functionality of the abstract data type IOV described by table 8 in section 5 of the position paper should be available. For full flexibility the atomic operations should be available as comparisons, see Table 9."

This motion is to be understood as a supplement to motion 13.04.
The advantages are outlined in the position paper that serves as
rationale for the motion.
<<<<


As Nate indicated in his vote an abstract data type is used.


Jürgen & Marco

--
     o           Marco Nehmeier, Lehrstuhl fuer Informatik II
    / \          Universitaet Wuerzburg, Am Hubland, D-97074 Wuerzburg
InfoII o         Tel.: +49 931 / 31 88684
  / \  Uni       E-Mail: nehmeier@xxxxxxxxxxxxxxxxxxxxxxxxxxx
 o   o Wuerzburg