So as long as the conversion constant (e.g., VQQ) matches the type
constant(e.g., RAT) the result bit could be anything as long as it is
unique to the rest? So, this would be okay:
#define VYY XD // This has to
match the type bit?
#define VARGMSK (VBB|VII|VDD|VZZ|Vxx|VQQ|VYY)
#define VY (VSB<<1) // This can be anything
unique to the rest?
#define VRESMSK (VB|VI|VD|VZ|VX|VQ|VSB|VY)
On 07/29/2016 03:06 PM, Henry Rich wrote:
It wouldn't be necessary to change VRESX to 29; we would put in
bit-by-bit tests as needed. I wanted to eliminate as much bit-testing
as possible for the usual cases.
I don't think reordering the type bits is possible, since user code
depends on the assignment.
Henry Rich
On 7/29/2016 3:00 PM, Thomas Costigliola wrote:
Are the changes to the bit patterns at the top of va.h supposed to
eliminate an extra lookup later?
#define VBB B01 /* convert arguments to
B */
#define VII INT /* convert arguments to
I */
#define VDD FL /* convert arguments to
D */
#define VZZ CMPX /* convert arguments to
Z */
#define Vxx XNUM /* convert arguments to
XNUM */
#define VQQ RAT /* convert arguments to
RAT */
#define VARGMSK (VBB|VII|VDD|VZZ|Vxx|VQQ) // mask for
argument requested type
#define VRESX 8 // bit position for result flags
But what happens if the extended floating point type (XD) gets
implemented? That would push VRESX to 29 and leave no room for
VXCVTTYPEX on 32 bit machines. I do have custom types beyond bit 29
and I would like to conform to the official source, what is the
recommendation? Reorder the type bit patterns?
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
