On 4/7/2011 9:42 AM, Angel Luis Domínguez wrote:
On Thu, 7 Apr 2011 14:32:56 +0300, Binyamin Dissen
wrote:
LE will LOAD the module on the first call and then BALR the later calls.
Change your ASM module to LOAD it and BALR as well.
I did it and now the results are for the same work in cpu sec
On Thu, Apr 7, 2011 at 3:20 PM, Edward Jaffe wrote:
>
>
> Is it just me??
>
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> 310-338-0400 x318
> edja...@phoenixsoftware.com
> http://www.phoenixsoftware.com/
>
No.
--
Mike Shaw
MVS/Qu
On Thu, Apr 7, 2011 at 12:20 PM, Edward Jaffe
wrote:
> On 4/7/2011 9:42 AM, Angel Luis Domínguez wrote:
>>
>> On Thu, 7 Apr 2011 14:32:56 +0300, Binyamin Dissen
>> wrote:
>>>
>>> LE will LOAD the module on the first call and then BALR the later calls.
>>> Change your ASM module to LOAD it and BA
> -Original Message-
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Edward Jaffe
> Sent: Thursday, April 07, 2011 2:21 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED
On Thu, 07 Apr 2011 15:20:41 -0400, Edward Jaffe
wrote:
I keep attending IBM presentations that assert the code generated by the C
compiler will outperform assembler. Some programmers I respect have asserted the
same thing. Every time I look into this I see the wonders of the C compiler's
opti
On Apr 7, 2011, at 14:02, Alex Kodat wrote:
>
> A programmer, on the other hand, even with only a glimmer of knowledge of
> what the program is doing can usually guess which if block is most likely to
> be executed so optimize the code for that if block, for example by holding
> registers and point
UGA.EDU
>> Subject: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED!)
>>
>> On 4/7/2011 9:42 AM, Angel Luis Domínguez wrote:
>> > On Thu, 7 Apr 2011 14:32:56 +0300, Binyamin Dissen
>> > wrote:
>> >> LE will LOAD the module on the first call and
On Thu, Apr 7, 2011 at 1:02 PM, Alex Kodat wrote:
> On Thu, 07 Apr 2011 15:20:41 -0400, Edward Jaffe
> wrote:
>
>> I keep attending IBM presentations that assert the code generated by the C
>> compiler will outperform assembler. Some programmers I respect have
>> asserted the
>> same thing. Every
On Thu, Apr 7, 2011 at 1:17 PM, Paul Gilmartin wrote:
> On Apr 7, 2011, at 14:02, Alex Kodat wrote:
>>
>> A programmer, on the other hand, even with only a glimmer of knowledge of
>> what the program is doing can usually guess which if block is most likely to
>> be executed so optimize the code fo
> -Original Message-
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Sam Siegel
> Sent: Thursday, April 07, 2011 3:41 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - S
EDU
>> Subject: Re: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED!)
>
>> It is a non-sequitur to say knowing a certain programing language
>> makes you better at designing and implementing algorithms. Analysis
>> of algorithms is more of a mathematical endeav
On Thu, 07 Apr 2011 16:45:10 -0400, Sam Siegel wrote:
Look at the IPA and Profile directed optimization available to the
C/C++ compiler. These features do exactly what you describe.
These look pretty cool. I'd say that PDF is closer to being able to get
the out of band "knowledge" that I was
On 7 April 2011 16:02, Alex Kodat wrote:
> There are always pieces of information that are extremely useful in optimizing
> code that are simply not present in the code itself so not possible for a
> compiler to use in optimization.
Some compilers, and more important, some languages, allow the
p
IBM Mainframe Assembler List wrote on
04/07/2011 05:49:24 PM:
> From: Tony Harminc
> But the whole thing stinks - inventing cute tricks to pass implicit
> knowledge *through* the language to the code generator. It would be
> much nicer to be able to explicitly provide hints that the compiler
> c
On Thu, Apr 7, 2011 at 2:47 PM, McKown, John
wrote:
>
> Of course, C programmers, as a general class, are not as good as HLASM
> programmers in designing and implementing algorithms.
(Always beware of an argument that begins with "Of course, ...")
Is this an assertion about C vs HLASM or good v
-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU]
On Behalf Of Sam Siegel
Sent: Thursday, April 07, 2011 4:30 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED!)
On Thu, Apr 7, 2011 at 1
About C:
> But the whole thing stinks - inventing cute tricks to pass implicit
> knowledge *through* the language to the code generator. It would be
> much nicer to be able to explicitly provide hints that the compiler
> could exploit according to its abilities.
But then there is D ! :)
(No, I
>Is it just me??
Probably not, but if someone is comparing a HLL C that uses LE runtime
stuff with assembler that doesn't, that is not a fair comparison.
How about comparing Metal C to assembler to take runtime out of the
equation?
An interesting, but almost inevitable, phenomenon is that if you
On Fri, Apr 8, 2011 at 1:35 PM, Peter Relson wrote:
> An interesting, but almost inevitable, phenomenon is that if you started
> with two programs, one in asssembler, one in a HLL, both highly optimized,
> over time, as that program is modified, the assembler one usually gets
> worse, and the HLL
> -Original Message-
> From: IBM Mainframe Assembler List
> [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of William M Klein
> Sent: 08 April 2011 05:34
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED!)
>
On Fri, Apr 8, 2011 at 4:33 PM, Edward Jaffe
wrote:
> There is also a propensity for programmers to suggest that 'everything'
> should
> be rewritten in whatever their language "du jour" happens to be. I'm always
> astonished when someone suggests with a straight face that several million
> lines
y 2008 time frame?
Bob Raicer
> Date:Thu, 7 Apr 2011 14:17:46 -0600
> From: Paul Gilmartin
> Subject: Re: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED!)
>
> OTOH, I am led to believe that some Java VMs do dynamic recompilation,
> monitoring the execution pr
nerates machine code rather than emulation.
>
> I wonder whatever happened to the PSI technology after IBM purchased
> the company around the July 2008 time frame?
>
> Bob Raicer
>
>> Date: Thu, 7 Apr 2011 14:17:46 -0600
>> From:Paul Gilmartin
>> Subject: R
On Fri, 8 Apr 2011 07:35:09 -0400, Peter Relson wrote:
>[...]
>An interesting, but almost inevitable, phenomenon is that if you started
>with two programs, one in asssembler, one in a HLL, both highly optimized,
>over time, as that program is modified, the assembler one usually gets
>worse, and t
m: IBM Mainframe Assembler List [mailto:ASSEMBLER-
> l...@listserv.uga.edu] On Behalf Of Justin R. Bendich
> Sent: Friday, April 08, 2011 3:56 PM
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED!)
>
> On Fri, 8
At 17:21 -0500 on 04/07/11, Kirk Wolf wrote about Re: ASM vs HLL
(Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED:
Lets have a more real world discussion -
Lets say that you have an HLASM and a C programmer of equal experience
who are independently building the same system and they need a good
On 4/8/2011 4:11 PM, Robert A. Rosenberg wrote:
The assembler programmer grabs his Knuth book
Or he digs into his tool box and pulls out a subroutine to do it
(ie:
The equivalent of your OS/PD implementation). If the C
Programmer is
allowed to cheat by using a pre-existent and debugged set
al Message-
From: IBM Mainframe Assembler List
[mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Robert A.
Rosenberg
Sent: Friday, April 08, 2011 15:12
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED!)
At 17:21 -0500 on 04/07/11, Kirk
.UGA.EDU] On Behalf Of Robert A.
> Rosenberg
> Sent: Friday, April 08, 2011 15:12
> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
> Subject: Re: ASM vs HLL (Was: CPU: ASSM vs ENTERPRISE COBOL - SOLVED!)
>
> At 17:21 -0500 on 04/07/11, Kirk Wolf wrote about Re: ASM vs HLL
> (Was: CPU: AS
On Fri, Apr 8, 2011 at 3:11 PM, Robert A. Rosenberg wrote:
>
>
> Or he digs into his tool box and pulls out a subroutine to do it (ie:
> The equivalent of your OS/PD implementation). If the C Programmer is
> allowed to cheat by using a pre-existent and debugged set of code (in
> lieu of creating i
On 4/9/2011 7:55 AM, Kirk Wolf wrote:
... and my point is that in the real world there is not only
more reusable "library" code in C but that it is easier to reuse,
being a HLL.
C is considered an HLL?
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, C
Many algorithms, for example quicksort or walking thru binary trees
or inserting into balanced trees like AVL trees etc., need to be written
as recursive functions or procedures. If you want to do this in ASSEMBLER,
you have to do all the housekeeping etc. to get the many incarnations of
variables
From all "HLLs", C is probably the lowest,
but from the ASSEMBLER coders viewpoint, this is good, not bad:
you always know very well, what machine code will be produced
out of your C code - there are no hidden secrets. At least, that's
my opinion.
And, see my previous post: you can easily use we
On 4/9/2011 11:50 AM, Bernd Oppolzer wrote:
Many algorithms, for example quicksort or walking thru binary trees
or inserting into balanced trees like AVL trees etc., need to be written
as recursive functions or procedures. If you want to do this in ASSEMBLER,
you have to do all the housekeeping e
We, too, have at our site a macro which supports the creation of
automatic storage, but at the module level. This is ok and it would solve
the problem of recursive calls. But it is far too expensive for a recursive
function like quicksort etc., where recursion is heavily used and where the
saving
On 4/9/2011 2:50 PM, Bernd Oppolzer wrote:
Many algorithms, for example quicksort or walking thru binary trees
or inserting into balanced trees like AVL trees etc., need to be
written
as recursive functions or procedures. If you want to do this in
ASSEMBLER,
you have to do all the housekeeping et
Kirk Wolf noted:
> Cheating is always encouraged :-), but I think that the point was that
neither programmer had such a routine "in his toolbox". The C programmer
will find something that is easily reused, the assembler guy probably
won't.
I thought the CBT tape actively encouraged "cheating".
On Sat, Apr 9, 2011 at 11:28 PM, John Ehrman wrote:
> Kirk Wolf noted:
>
>> Cheating is always encouraged :-), but I think that the point was that
> neither programmer had such a routine "in his toolbox". The C programmer
> will find something that is easily reused, the assembler guy probably
>
38 matches
Mail list logo
