In
caajsdjgvpp5c-jwq5to-hmogrfxve-x3+nm0ej_xl6vsmm4...@mail.gmail.com,
on 02/26/2014
at 08:56 AM, John McKown john.archie.mck...@gmail.com said:
My bad. I couldn't do a cut and paste. So I had to type in by
hand. Which I did not double check. My hands sometimes just
automagically type in
In
ofe4016b7d.cd5a426d-on85257c89.0047d56f-85257c89.00480...@us.ibm.com,
on 02/24/2014
at 08:06 AM, Peter Relson rel...@us.ibm.com said:
SLR R0,R0
IC R1,0(,R1)
CHI R1,=H'13'
BNE ...
Ignoring that this is lousy code
Will it even assemble? Should the CHI not have an immediate value
rather
My bad. I couldn't do a cut and paste. So I had to type in by hand. Which I
did not double check. My hands sometimes just automagically type in what
_they_ think should be there instead of what my brain says to type. I think
they learned this from my mouth/vocal chords.
On Tue, Feb 25, 2014 at
SLR R0,R0
IC R1,0(,R1)
CHI R1,=H'13'
BNE ...
Ignoring that this is lousy code (unless, perhaps, the value is looked at
again, in which case having it in a reg could be advantageous), I hope
that this was a slightly incomplete snippet, or a typo; R1 needs to be
zeroed for the IC/CHI, not
On Mon, Feb 24, 2014 at 7:06 AM, Peter Relson rel...@us.ibm.com wrote:
SLR R0,R0
IC R1,0(,R1)
CHI R1,=H'13'
BNE ...
Ignoring that this is lousy code (unless, perhaps, the value is looked at
again, in which case having it in a reg could be advantageous), I hope
that this was a slightly
john.archie.mck...@gmail.com (John McKown) writes:
Wasn't there something about a PASCAL programmer knowing the value of
everything and the Wirth of nothing?
two people from the Los Gatos VLSI lab originally did mainframe pascal
for VLSI chip tools ... this goes on eventually to become the
Again, my thanks to all for the help, which was my fault in not realizing
that I had used the -o switch instead of the -O switch and so was not
having my code optimized.
On the off chance that anybody was wondering why I was doing this, it was
just a test to try to determine the best way to see
On 24 February 2014 10:44, Anne Lynn Wheeler l...@garlic.com wrote:
two people from the Los Gatos VLSI lab originally did mainframe pascal
for VLSI chip tools ... this goes on eventually to become the vs/pascal
product. Amoung other things it was used to implement the original
mainframe
t...@harminc.net (Tony Harminc) writes:
You've mentioned this a number of times, but I don't think you've
explained what you did to the Pascal code to get a 500x improvement.
Was the original code exceptionally bad, was your new code
exceptionally brilliant, did you take advantage of some
Was the original code exceptionally bad, was your new code exceptionally
brilliant,
When I worked on Strobe we saw this all of the time. One shop saw job runtime
drop from 24 hours to eight minutes. We could only wonder what they had done
in the first place.
Bob Shannon
Ex-Programart
I bet if you timed it the strchr() TRT in a loop is faster.
On 25/02/2014, at 12:19 AM, John McKown john.archie.mck...@gmail.com wrote:
Again, my thanks to all for the help, which was my fault in not realizing
that I had used the -o switch instead of the -O switch and so was not
having my
As I posted recently in another thread, I certainly appreciate the intellectual
challenge etc., etc. of finding the absolute fastest way of performing some
machine function.
However, I hope you realize that in real life the exact speed of TRT versus
SRST is going to be dwarfed by the cost of
On Sun, Feb 23, 2014 at 12:44 AM, David Crayford dcrayf...@gmail.comwrote:
Hmm, I'm not getting the same result! When I compile with ARCH(5) there is
only one strlen() call (SRST) and the value is retained in a register.
BTW, I removed #undef strlen. What is the purpose of that directive?
*
I would strongly suggest not to #undef such #defines coming from the
standard headers; the results may be unpredictable.
Maybe the compiler optimization and inlining strategies relies
exactly on such #defines, that is:
strlen needs to be __strlen, so that the compiler can recognize it
and do
An explanation, which is just a little more paranoid:
if you #undef strlen, the compiler cannot be sure, if your strlen
is not quite another function, which does not give the same result
on two subsequent calls ... ???
Original-Nachricht
Betreff: Re: Curious observation:
I guess that IBM #defines some well known ANSI functions to
other strange names (__strlen for strlen, as an example), to be able
to do some special optimizations on those functions after or before
inlining them. Remember, the names of the ANSI functions are not
reserved in C - they are not part
Historically, the term 'builtin' is of course a PL/I one that has been
adopted elsewhere too, e.g., by the HLASM. In PL/I it refers to
implementation-supplied functions. Some of
these, like SQRT and COSH, are always implemented by calls to library
routines; some of them, like LENGTH and SIGN,
On Sun, Feb 23, 2014 at 12:48 PM, Bernd Oppolzer bernd.oppol...@t-online.de
wrote:
I would strongly suggest not to #undef such #defines coming from the
standard headers; the results may be unpredictable.
Maybe the compiler optimization and inlining strategies relies
exactly on such
Right. There is an XLC compiler option ANSIFUNCS or something like that. (Too
lazy to look it up.) It tells the compiler things that have the names of
standard functions really ARE standard functions. Without that option turned
on, strlen() could be a private random number generator.
Charles
On 23/02/2014 11:55 PM, John McKown wrote:
I don't know why that would make a difference.
Would you mind showing me your compile parameters? What version of z/OS are
you running on? My compile came from a z/OS 1.13 system. I don't know the
maintenance level.
z/OS 1.13
c99_x -O
I'm checking into to the old folks home soon. Instead of using -O5, I used
-o5. Which did not cause any problem because that means write the output
object code to the file named 5. I guess I was sleepier than I thought
yesterday and just didn't catch that.
My error, and my thanks to all for your
Dang C case-sensitivity!
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of John McKown
Sent: Sunday, February 23, 2014 5:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Curious observation: lack of a simple optimization in a C
On 24/02/2014 9:58 AM, John McKown wrote:
I'm checking into to the old folks home soon. Instead of using -O5, I used
-o5. Which did not cause any problem because that means write the output
object code to the file named 5. I guess I was sleepier than I thought
yesterday and just didn't catch
Just for fun, I wrote a very small C program. I compiled it on Linux/Intel
using GCC 4.8.2. I then got it compiled on z/OS 1.13. The program is very
small:
#include stdlib.h
#include stdio.h
#include string.h
#undef strlen
int main (int argc, char *argv[]) {
int i;
for(i=0;iargc;i++) {
Hmm, I'm not getting the same result! When I compile with ARCH(5) there
is only one strlen() call (SRST) and the value is retained in a register.
BTW, I removed #undef strlen. What is the purpose of that directive?
* int i;
* for(i=0;iargc;i++) {
LTR r1,r1
LA
25 matches
Mail list logo
