REXX v. NetREXX Concordance

[Robert L Hamilton]

I guess we could put all the rexx things in a 'program' and run it thru Tom's converter.

Maybe si, maybe no ?

BobH

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Thomas.Schneider.Wien]

Hello Bob, (*and* all)

Intentionally, *yes*.

The current (ancient version) should work 99 % OK for *classic IBM COMPILED Rexx*.

Except INTERPRET ad TRACE which have ot been implemented at those times.

Sad to say, I did start an effort to PORT again Rexx2Nrx to NetRexx, by using
an experimental version of my *class Builder*.

Sad also to say, that I didn't release all of this stuff yet....

... Happy to say as I'm currently working to translate PL/I and COBOL
to NetRexx....

Thomas.
==================================================================


Am 30.10.2010 22:25, schrieb Robert Hamilton:

I guess we could put all the rexx things in a 'program' and run it thru Tom's converter.

Maybe si, maybe no ?

BobH

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[alansam]

On 30 October 2010 22:08, Thomas Schneider <[hidden email]> wrote:

Hello Bob, (*and* all)

Intentionally, *yes*.

The current (ancient version) should work 99 % OK for *classic IBM COMPILED Rexx*.

Except INTERPRET ad TRACE which have ot been implemented at those times.

Sad to say, I did start an effort to PORT again Rexx2Nrx to NetRexx, by using
an experimental version of my *class Builder*.

Sad also to say, that I didn't release all of this stuff yet....

... Happy to say as I'm currently working to translate PL/I and COBOL
to NetRexx....

Except that if you want to benchmark a language (a questionable effort in itself), running non-native code through a code converter to generate target source isn't benchmarking the language in question it's benchmarking the converter.

Code converters by necessity have to make compromises; to get any sort of valuable benchmark you must write the tests in the target language and make best efforts to choose the most efficient way to implement algorithms that demonstrate the language's best performance paths.

Alan.
--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[rvjansen]

I agree that it is questionable in many ways, and still people do it a lot - benchmarking languages/environments/hardware.

There is some sense to it, tho. Write something in JRuby and I am sure that a lot of people with some experience on modern platforms will think: "Whoa, what is wrong here?" And when they express the same thing in NetRexx they will have no qualms about the performance. Of course, that same program in JRuby might function very well in a Web container as part of a site, where different rules apply.

I am certain that for some cases performance of programs written in NetRexx might outshine the same programs written in Java syntax. Like the C compiler writes better assembler code than we generally do, on CISC by avoiding those expensive storage to storage instructions, and on RISC by remembering the cycles in which you can use storage locations and knowing about all those pipelines, it must be that 'parse' writes better parsers than a Java programmer writes the same thing using regular expressions. It might be interesting to have research done on this, and this is why the benchmarks do matter.

best regards,

René Jansen.

On 31 okt 2010, at 16:51, Alan Sampson wrote:

On 30 October 2010 22:08, Thomas Schneider <[hidden email]> wrote:

Hello Bob, (*and* all)

Intentionally, *yes*.

The current (ancient version) should work 99 % OK for *classic IBM COMPILED Rexx*.

Except INTERPRET ad TRACE which have ot been implemented at those times.

Sad to say, I did start an effort to PORT again Rexx2Nrx to NetRexx, by using
an experimental version of my *class Builder*.

Sad also to say, that I didn't release all of this stuff yet....

... Happy to say as I'm currently working to translate PL/I and COBOL
to NetRexx....

Except that if you want to benchmark a language (a questionable effort in itself), running non-native code through a code converter to generate target source isn't benchmarking the language in question it's benchmarking the converter.

Code converters by necessity have to make compromises; to get any sort of valuable benchmark you must write the tests in the target language and make best efforts to choose the most efficient way to implement algorithms that demonstrate the language's best performance paths.

Alan.
--
Can't tweet, won't tweet!
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[Mike Cowlishaw]

 >  I am certain that for some cases performance of programs written in NetRexx might outshine the same programs written in Java syntax.  

 

A simple example of that is the NetRexx (also all the way back to FORTRAN):

 

  do i=1 to x

 

compared to:

 

  for (i=1, i<=x; i++)

 

The semantics of NetRexx mean that 'x' (which might be a complicated expression including external call(s)) need only be evaluated once, whereas in the second case it has to be evaluated every time around the loop.

 

Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]

[christel.u.w.pachl christel.u.w.pachl]

The equivalent to (b) would be

Do i=1 By 1 while i<=x  which would re-evaluate x

Similar I never know if b is evaluated in

If a ! b ! c Then  

If a is found to be true

That was different in PL/I Optimizer vs. Checkout Compiler as far as I remember

---- Mike Cowlishaw <[hidden email]> schrieb:

>  >  I am certain that for some cases performance of programs written in NetRexx
> might outshine the same programs written in Java syntax.  
>  
> A simple example of that is the NetRexx (also all the way back to FORTRAN):
>  
>   do i=1 to x
>  
> compared to:
>  
>   for (i=1, i<=x; i++)
>  
> The semantics of NetRexx mean that 'x' (which might be a complicated expression
> including external call(s)) need only be evaluated once, whereas in the second
> case it has to be evaluated every time around the loop.
>  
> Mike

_______________________________________________
Ibm-netrexx mailing list
[hidden email]