NetRexxC "accepts" C shift operators without complaint

[George Hovey-2]

While converting C code to NetRexx, I inadvertently ran NetRexxC before dealing with some C shift operators ('>>', '<<'):

   Value = -
      (Rc_FlipA[(Value>>12)&0xF]<<12)  -
      |                                -
      (Rc_FlipA[(Value>>8)&0xF]<<8)    -
      |                                -
      (Rc_FlipA[(Value>>4)&0xF]<<4)    -
      |                                -
      (Rc_FlipA[Value&0xF])
     
I was surprised to see NetRexxC absorb this without a peep.  It produced

   Value=((((((Rc_FlipA[(((Value>12)?1:0))&15])<12))|(((Rc_FlipA[(((Value>8)?1:0))&15])<8)))|(((Rc_FlipA[(((Value>4)?1:0))&15])<4))?1:0))|((Rc_FlipA[Value&15]));

That is, it silently replaced '>>' with '>' and '<<' with '<'.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

>> and << are valid operators in NetRexx (Strictly greater than and Strictly less than).

 

Mike

---

While converting C code to NetRexx, I inadvertently ran NetRexxC before dealing with some C shift operators ('>>', '<<'):

   Value = -
      (Rc_FlipA[(Value>>12)&0xF]<<12)  -
      |                                -
      (Rc_FlipA[(Value>>8)&0xF]<<8)    -
      |                                -
      (Rc_FlipA[(Value>>4)&0xF]<<4)    -
      |                                -
      (Rc_FlipA[Value&0xF])
     
I was surprised to see NetRexxC absorb this without a peep.  It produced

   Value=((((((Rc_FlipA[(((Value>12)?1:0))&15])<12))|(((Rc_FlipA[(((Value>8)?1:0))&15])<8)))|(((Rc_FlipA[(((Value>4)?1:0))&15])<4))?1:0))|((Rc_FlipA[Value&15]));

That is, it silently replaced '>>' with '>' and '<<' with '<'.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

I tried searching NLR 3.04 GA for '>>' and '<<' without finding anything useful.  The problem seems to be

   TABLE 4: Normal comparative operators

where the strict operators are represented by guillemets rather than double angle brackets.

On Sun, May 29, 2016 at 11:58 AM, Mike Cowlishaw <[hidden email]> wrote:

>> and << are valid operators in NetRexx (Strictly greater than and Strictly less than).

 

Mike

---

While converting C code to NetRexx, I inadvertently ran NetRexxC before dealing with some C shift operators ('>>', '<<'):

   Value = -
      (Rc_FlipA[(Value>>12)&0xF]<<12)  -
      |                                -
      (Rc_FlipA[(Value>>8)&0xF]<<8)    -
      |                                -
      (Rc_FlipA[(Value>>4)&0xF]<<4)    -
      |                                -
      (Rc_FlipA[Value&0xF])
     
I was surprised to see NetRexxC absorb this without a peep.  It produced

   Value=((((((Rc_FlipA[(((Value>12)?1:0))&15])<12))|(((Rc_FlipA[(((Value>8)?1:0))&15])<8)))|(((Rc_FlipA[(((Value>4)?1:0))&15])<4))?1:0))|((Rc_FlipA[Value&15]));

That is, it silently replaced '>>' with '>' and '<<' with '<'.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Actually, guillemets appear in a number places.

On Sun, May 29, 2016 at 12:37 PM, George Hovey <[hidden email]> wrote:

I tried searching NLR 3.04 GA for '>>' and '<<' without finding anything useful.  The problem seems to be

   TABLE 4: Normal comparative operators

where the strict operators are represented by guillemets rather than double angle brackets.

On Sun, May 29, 2016 at 11:58 AM, Mike Cowlishaw <[hidden email]> wrote:

>> and << are valid operators in NetRexx (Strictly greater than and Strictly less than).

 

Mike

---

While converting C code to NetRexx, I inadvertently ran NetRexxC before dealing with some C shift operators ('>>', '<<'):

   Value = -
      (Rc_FlipA[(Value>>12)&0xF]<<12)  -
      |                                -
      (Rc_FlipA[(Value>>8)&0xF]<<8)    -
      |                                -
      (Rc_FlipA[(Value>>4)&0xF]<<4)    -
      |                                -
      (Rc_FlipA[Value&0xF])
     
I was surprised to see NetRexxC absorb this without a peep.  It produced

   Value=((((((Rc_FlipA[(((Value>12)?1:0))&15])<12))|(((Rc_FlipA[(((Value>8)?1:0))&15])<8)))|(((Rc_FlipA[(((Value>4)?1:0))&15])<4))?1:0))|((Rc_FlipA[Value&15]));

That is, it silently replaced '>>' with '>' and '<<' with '<'.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--

--

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

"Not my problem/fault",  I think. 

 

:-)

 

Mike

---

Actually, guillemets appear in a number places.

On Sun, May 29, 2016 at 12:37 PM, George Hovey <[hidden email]> wrote:

I tried searching NLR 3.04 GA for '>>' and '<<' without finding anything useful.  The problem seems to be

   TABLE 4: Normal comparative operators

where the strict operators are represented by guillemets rather than double angle brackets.

On Sun, May 29, 2016 at 11:58 AM, Mike Cowlishaw <[hidden email]> wrote:

>> and << are valid operators in NetRexx (Strictly greater than and Strictly less than).

 

Mike

---

While converting C code to NetRexx, I inadvertently ran NetRexxC before dealing with some C shift operators ('>>', '<<'):

   Value = -
      (Rc_FlipA[(Value>>12)&0xF]<<12)  -
      |                                -
      (Rc_FlipA[(Value>>8)&0xF]<<8)    -
      |                                -
      (Rc_FlipA[(Value>>4)&0xF]<<4)    -
      |                                -
      (Rc_FlipA[Value&0xF])
     
I was surprised to see NetRexxC absorb this without a peep.  It produced

   Value=((((((Rc_FlipA[(((Value>12)?1:0))&15])<12))|(((Rc_FlipA[(((Value>8)?1:0))&15])<8)))|(((Rc_FlipA[(((Value>4)?1:0))&15])<4))?1:0))|((Rc_FlipA[Value&15]));

That is, it silently replaced '>>' with '>' and '<<' with '<'.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--

--

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

My problem/fault - I will escape these in TeX. The typographic zeal is too much here.

best regards,

René.

 

On 29 mei 2016, at 20:33, Mike Cowlishaw <[hidden email]> wrote:

"Not my problem/fault",  I think. 

 

:-)

 

Mike

---

Actually, guillemets appear in a number places.

On Sun, May 29, 2016 at 12:37 PM, George Hovey <[hidden email]> wrote:

I tried searching NLR 3.04 GA for '>>' and '<<' without finding anything useful.  The problem seems to be

   TABLE 4: Normal comparative operators

where the strict operators are represented by guillemets rather than double angle brackets.

On Sun, May 29, 2016 at 11:58 AM, Mike Cowlishaw <[hidden email]> wrote:

>> and << are valid operators in NetRexx (Strictly greater than and Strictly less than).

 

Mike

---

While converting C code to NetRexx, I inadvertently ran NetRexxC before dealing with some C shift operators ('>>', '<<'):

   Value = -
      (Rc_FlipA[(Value>>12)&0xF]<<12)  -
      |                                -
      (Rc_FlipA[(Value>>8)&0xF]<<8)    -
      |                                -
      (Rc_FlipA[(Value>>4)&0xF]<<4)    -
      |                                -
      (Rc_FlipA[Value&0xF])
     
I was surprised to see NetRexxC absorb this without a peep.  It produced

   Value=((((((Rc_FlipA[(((Value>12)?1:0))&15])<12))|(((Rc_FlipA[(((Value>8)?1:0))&15])<8)))|(((Rc_FlipA[(((Value>4)?1:0))&15])<4))?1:0))|((Rc_FlipA[Value&15]));

That is, it silently replaced '>>' with '>' and '<<' with '<'.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--

--

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Any chance guillemets could represent binary shifts on integer types with Java semantics?  Believe it or not, quite a bit of hardware level code is written in Java.  NetRexx is even better except for dealing with shifts via functions.

There are three shifts
   1. "<<"  Shift Left Logical     (0s inserted on right)
   2. ">>"  Shift Right Arithmetic (sign extension)

   3. ">>>" Shift Right Logical    (0s inserted on left)

[Hope springs eternal.]

On Sun, May 29, 2016 at 3:23 PM, René Jansen <[hidden email]> wrote:

My problem/fault - I will escape these in TeX. The typographic zeal is too much here.

best regards,

René.

 

On 29 mei 2016, at 20:33, Mike Cowlishaw <[hidden email]> wrote:

"Not my problem/fault",  I think. 

 

:-)

 

Mike

---

Actually, guillemets appear in a number places.

On Sun, May 29, 2016 at 12:37 PM, George Hovey <[hidden email]> wrote:

I tried searching NLR 3.04 GA for '>>' and '<<' without finding anything useful.  The problem seems to be

   TABLE 4: Normal comparative operators

where the strict operators are represented by guillemets rather than double angle brackets.

On Sun, May 29, 2016 at 11:58 AM, Mike Cowlishaw <[hidden email]> wrote:

>> and << are valid operators in NetRexx (Strictly greater than and Strictly less than).

 

Mike

---

While converting C code to NetRexx, I inadvertently ran NetRexxC before dealing with some C shift operators ('>>', '<<'):

   Value = -
      (Rc_FlipA[(Value>>12)&0xF]<<12)  -
      |                                -
      (Rc_FlipA[(Value>>8)&0xF]<<8)    -
      |                                -
      (Rc_FlipA[(Value>>4)&0xF]<<4)    -
      |                                -
      (Rc_FlipA[Value&0xF])
     
I was surprised to see NetRexxC absorb this without a peep.  It produced

   Value=((((((Rc_FlipA[(((Value>12)?1:0))&15])<12))|(((Rc_FlipA[(((Value>8)?1:0))&15])<8)))|(((Rc_FlipA[(((Value>4)?1:0))&15])<4))?1:0))|((Rc_FlipA[Value&15]));

That is, it silently replaced '>>' with '>' and '<<' with '<'.

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--

--

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

 

Any chance guillemets could represent binary shifts on integer types with Java semantics?  Believe it or not, quite a bit of hardware level code is written in Java.  NetRexx is even better except for dealing with shifts via functions.

There are three shifts
   1. "<<"  Shift Left Logical     (0s inserted on right)
   2. ">>"  Shift Right Arithmetic (sign extension) 

 

As I mentioned before, those two operator symbol/combinations already exist and are defined in NetRexx.  Making them mean something else would break any existing NetRexx program that used them.

 

As also discussed recently, they really do not need special operators: just use multiply or integer divide (and these will work on decimal values too). 

 

"Shift right logical" is a touch trickier, but if you really need that you fully understand what you are doing and it won't take you very long to work out how to do it.  :-)

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

With unicode support there is no reason we could not implement the guillemet codepoints as shifts, as long as we don't  change the meaning of the plain pointy brackets. I foresee problems on non-unicode platforms though.

René.

On 29 May 2016, at 22:21, Mike Cowlishaw <[hidden email]> wrote:

 

Any chance guillemets could represent binary shifts on integer types with Java semantics?  Believe it or not, quite a bit of hardware level code is written in Java.  NetRexx is even better except for dealing with shifts via functions.

There are three shifts
   1. "<<"  Shift Left Logical     (0s inserted on right)
   2. ">>"  Shift Right Arithmetic (sign extension) 

 

As I mentioned before, those two operator symbol/combinations already exist and are defined in NetRexx.  Making them mean something else would break any existing NetRexx program that used them.

 

As also discussed recently, they really do not need special operators: just use multiply or integer divide (and these will work on decimal values too). 

 

"Shift right logical" is a touch trickier, but if you really need that you fully understand what you are doing and it won't take you very long to work out how to do it.  :-)

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Kermit Kiser]

I have to vote with Mike on this one. Guillemets would be a very bad choice for a NetRexx operator. If you absolutely must add special operators for binary shifts, they cannot look like existing NetRexx operators! Also since Java does not use the "guillemets" for shifts, they would be extremely confusing to Java programmers trying NetRexx.

-- Kermit

On 2016-05-29 1:28 PM, René Jansen wrote:

With unicode support there is no reason we could not implement the guillemet codepoints as shifts, as long as we don't  change the meaning of the plain pointy brackets. I foresee problems on non-unicode platforms though.

René.

On 29 May 2016, at 22:21, Mike Cowlishaw <[hidden email]> wrote:

 

Any chance guillemets could represent binary shifts on integer types with Java semantics?  Believe it or not, quite a bit of hardware level code is written in Java.  NetRexx is even better except for dealing with shifts via functions.

There are three shifts
   1. "<<"  Shift Left Logical     (0s inserted on right)
   2. ">>"  Shift Right Arithmetic (sign extension) 

 

As I mentioned before, those two operator symbol/combinations already exist and are defined in NetRexx.  Making them mean something else would break any existing NetRexx program that used them.

 

As also discussed recently, they really do not need special operators: just use multiply or integer divide (and these will work on decimal values too). 

 

"Shift right logical" is a touch trickier, but if you really need that you fully understand what you are doing and it won't take you very long to work out how to do it.  :-)

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[rvjansen]

I did not think Mike made exactly this point, but I agree.

For the rest, I would refer to Java BitSet which does provide a lot of the basics to implement this.

best regards,

René.

 

On 30 mei 2016, at 08:28, Kermit Kiser <[hidden email]> wrote:

I have to vote with Mike on this one. Guillemets would be a very bad choice for a NetRexx operator. If you absolutely must add special operators for binary shifts, they cannot look like existing NetRexx operators! Also since Java does not use the "guillemets" for shifts, they would be extremely confusing to Java programmers trying NetRexx.

-- Kermit

On 2016-05-29 1:28 PM, René Jansen wrote:

With unicode support there is no reason we could not implement the guillemet codepoints as shifts, as long as we don't  change the meaning of the plain pointy brackets. I foresee problems on non-unicode platforms though.

René.

On 29 May 2016, at 22:21, Mike Cowlishaw <[hidden email][hidden email]> wrote:

 

Any chance guillemets could represent binary shifts on integer types with Java semantics?  Believe it or not, quite a bit of hardware level code is written in Java.  NetRexx is even better except for dealing with shifts via functions.

There are three shifts
   1. "<<"  Shift Left Logical     (0s inserted on right)
   2. ">>"  Shift Right Arithmetic (sign extension) 

 

As I mentioned before, those two operator symbol/combinations already exist and are defined in NetRexx.  Making them mean something else would break any existing NetRexx program that used them.

 

As also discussed recently, they really do not need special operators: just use multiply or integer divide (and these will work on decimal values too). 

 

"Shift right logical" is a touch trickier, but if you really need that you fully understand what you are doing and it won't take you very long to work out how to do it.  :-)

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

OK, I surrender.

On Mon, May 30, 2016 at 8:56 AM, René Jansen <[hidden email]> wrote:

I did not think Mike made exactly this point, but I agree.

For the rest, I would refer to Java BitSet which does provide a lot of the basics to implement this.

best regards,

René.

 

On 30 mei 2016, at 08:28, Kermit Kiser <[hidden email]> wrote:

I have to vote with Mike on this one. Guillemets would be a very bad choice for a NetRexx operator. If you absolutely must add special operators for binary shifts, they cannot look like existing NetRexx operators! Also since Java does not use the "guillemets" for shifts, they would be extremely confusing to Java programmers trying NetRexx.

-- Kermit

On 2016-05-29 1:28 PM, René Jansen wrote:

With unicode support there is no reason we could not implement the guillemet codepoints as shifts, as long as we don't  change the meaning of the plain pointy brackets. I foresee problems on non-unicode platforms though.

René.

On 29 May 2016, at 22:21, Mike Cowlishaw <[hidden email][hidden email]> wrote:

 

Any chance guillemets could represent binary shifts on integer types with Java semantics?  Believe it or not, quite a bit of hardware level code is written in Java.  NetRexx is even better except for dealing with shifts via functions.

There are three shifts
   1. "<<"  Shift Left Logical     (0s inserted on right)
   2. ">>"  Shift Right Arithmetic (sign extension) 

 

As I mentioned before, those two operator symbol/combinations already exist and are defined in NetRexx.  Making them mean something else would break any existing NetRexx program that used them.

 

As also discussed recently, they really do not need special operators: just use multiply or integer divide (and these will work on decimal values too). 

 

"Shift right logical" is a touch trickier, but if you really need that you fully understand what you are doing and it won't take you very long to work out how to do it.  :-)

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/