Fortran - Re: Reduce Blanks challenge

Author

Re: Reduce Blanks challenge

robin

2005-08-20, 9:56 pm

David Frank wrote in message ...
>Since its obvious there is NO PL/I solution to translate my 1-line
>Count_Items challenge via a single scan thru
>the input line,

get string(trim(line)) list ((v do COUNT = 1 to length(line));

>then we can go on to a 2nd challenge thats been running concurrently over in
>comp.lang.fortran.
>Posted only for PLI'er info, there wont be a PL/I translation.
>
>Since its my challenge I am narrowing the acceptable solutions in reduce.f90
>as follows:
>
>3. Fast/Legible/Brief is a goal.

Yours does not meet your own "criterion". Giles says that your
code is "ugly".

=======
From: James Giles <jamesgiles@worldnet.att.net>
Subject: Re: Reduce Blanks continued
Date: Friday, 19 August 2005 14:07

David Frank wrote:

> 2. set which chars are to be preserved in a logical mask (note
> the NEW 1-liner)
>
> out = [ .true., (a(i)/=' '.or.a(i-1)/=' ',i=2,len(line)) ]

This is ugly and less legible than my code

David Frank

2005-08-21, 7:56 am

"robin" <robin_v@bigpond.com> wrote in message
news:4vRNe.5947$FA3.5307@news-server.bigpond.net.au...
>
> David Frank wrote in message ...
>
> get string(trim(line)) list ((v do COUNT = 1 to length(line));
>
>
> Yours does not meet your own "criterion". Giles says that your
> code is "ugly".
>
>
> =======
> From: James Giles <jamesgiles@worldnet.att.net>
> Subject: Re: Reduce Blanks continued
> Date: Friday, 19 August 2005 14:07
>
> David Frank wrote:
>
>
> This is ugly and less legible than my code
>
>
>

Giles thinks his own code is more legible which opinion I think starts and
ends with him ..
His statements to set his flag mask are opaque to reader on first encounter.
What do you think about my 1 statement vs. below, do you agree with him?

flag = c == ' '
flag(2:) = .not.(flag(:len(line)-1) .and. flag(2:))
flag(1) = .true.

In any case, your next message (also cross-posted BY YOU from
comp.lang.pl1) shows my insightful 2char test (that Giles and everyone
overlooked and is source of his pique) adapts to array syntax and is
imbedded into

outline = line(1:1) // Copy( PACK(a(2:), a(2:) /= ' ' .OR. a(1:) /= '
', pad) )

James J. Weinkam

2005-08-21, 6:57 pm

robin wrote:
> David Frank wrote in message ...
>
>
>
> get string(trim(line)) list ((v do COUNT = 1 to length(line));
>
This won't work as you intend. Even after you fix the missing parenthesis
error, the statement will raise the ERROR condition and the value of COUNT at
that point will be one too large.

James Giles

2005-08-21, 6:57 pm

David Frank wrote:
....
> In any case, your next message (also cross-posted BY YOU from
> comp.lang.pl1) shows my insightful 2char test (that Giles and
> everyone overlooked and is source of his pique) adapts to array
> syntax and is imbedded into
>
> outline = line(1:1) // Copy( PACK(a(2:), a(2:) /= ' ' .OR.
> a(1:) /= ' ', pad) )

This is a broken code. A(2:) is not conformable to A(1:)
and the results of the two compares cannot be .OR.ed to
each other. You would have to do something like the
following to fix it:

outline = line(1:1) // Copy( PACK(a(2:), a(2:) /= ' ' .OR.
> a(1:len(line)-1) /= ' ', pad) )

If you fix that, it still calls for each value of the array
(except the first) to be compared to blank *twice*. That's
a pessimization my code doesn't require. Sure a good
optimizer *might* find it and reconstruct *my* original
code.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

David Frank

2005-08-21, 6:57 pm

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...
> David Frank wrote:
> ...
>
> This is a broken code. A(2:) is not conformable to A(1:)

CVF sees Pack ( A(2:) , A(2:) /= ' ' are same size arrays and A(1:) is
at least larger,
thus it has no reason to complain, CVF is smart!!!

> and the results of the two compares cannot be .OR.ed to
> each other. You would have to do something like the
> following to fix it:
>
> outline = line(1:1) // Copy( PACK(a(2:), a(2:) /= ' ' .OR.
>
> If you fix that,

CVF says there is NOTHING TO FIX...

it still calls for each value of the array
> (except the first) to be compared to blank *twice*. That's
> a pessimization my code doesn't require. Sure a good
> optimizer *might* find it and reconstruct *my* original
> code.

Ha ha what a bitter pill for you to swallow seeing how simple the 2 char OR
logic is,
only one of which WILL EXECUTE.

Rich Townsend

2005-08-21, 6:57 pm

David Frank wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...
>
>
>
> CVF sees Pack ( A(2:) , A(2:) /= ' ' are same size arrays and A(1:) is
> at least larger,
> thus it has no reason to complain, CVF is smart!!!
>

No, A(1:) and A(2:) are not conformable, therefore your code violates
the standard - exactly as Giles pointed out.

That CVF does not pick up on this is probably because you are running
without array bounds checking. Could you re-run with checking enabled,
and post the results to this forum? I'm curious as to whether CVF is
broken in this respect, or whether the problem is just with your
comprehension of the standard.

cheers,

Rich

James Giles

2005-08-21, 6:57 pm

David Frank wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...
>
> CVF sees Pack ( A(2:) , A(2:) /= ' ' are same size arrays and
> A(1:) is at least larger,
> thus it has no reason to complain, CVF is smart!!!

You mean CVF is stupid in this instance. There is no
reson for confomability tests to be removed in this kind
of case.

You delusional and getting worse. The rest of your
diatribe is beneath contempt and not even worthy of
response. Say something with technical merit and
people will take you more seriously.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

David Frank

2005-08-22, 7:57 am

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...

> and the results of the two compares cannot be .OR.ed to
> each other. You would have to do something like the
> following to fix it:
>

The "results of the two compares cannot be .OR.ed to each other" ?????

Thats not happening, when pack sees the first test for a char existing
which happens 5x more frequently than the
OPTIONAL 2nd test involving the previous char, it immediately packs the
char and MOVES ON,
BECAUSE its a OR not a AND

David Frank

2005-08-22, 7:57 am

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:deb1ie$4qc$1@scrotar.nss.udel.edu...
> David Frank wrote:

> No, A(1:) and A(2:) are not conformable, therefore your code violates the
> standard - exactly as Giles pointed out.
>
> That CVF does not pick up on this is probably because you are running
> without array bounds checking. Could you re-run with checking enabled, and
> post the results to this forum? I'm curious as to whether CVF is broken in
> this respect, or whether the problem is just with your comprehension of
> the standard.
>

And I'm curious if ANYONE's compiler rejects my statement..

Explain how could there be ANY possibility of exceeding array bounds?

The DRIVING index is being conducted by PACK's array a(2:) and its size
AND bounds are CONTAINED
within a(1:) which makes CVF happy.

David Frank

2005-08-22, 7:57 am

OK, when I was experimenting using my PACK syntax in a test program
suddenly CVF got unhappy with the identical PACK syntax that was acceptable
in my strings.f90 file..
So I am WRONG, acceptance is NOT assured and I have updated my
REDUCE_BLANKS function in

http://home.earthlink.net/~dave_gemini/strings.f90

accordingly to use PACK ( a(2:), a(2:) /= ' ' .OR. a(1:LEN(LINE)-1) /=
' '), pad )

This is a CVF bug,
also noted is removing the -1 from the LEN(LINE) also made it accept the
statement in my test program.

Rich Townsend

2005-08-22, 7:02 pm

David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:deb1ie$4qc$1@scrotar.nss.udel.edu...
>
>
>
>
>
> And I'm curious if ANYONE's compiler rejects my statement..
>
> Explain how could there be ANY possibility of exceeding array bounds?
>
> The DRIVING index is being conducted by PACK's array a(2:) and its size
> AND bounds are CONTAINED
> within a(1:) which makes CVF happy.

CVF may be happy, but it is wrong. By your absurd argument, the
following code should work without problem:

---
program test_conf

character(1), dimension(30), allocatable :: a

a = TRANSFER(' The quick brown fox ', ' ')

print *, a(2:) /= ' ' .OR. a(1:) /= ' '

end program test_conf
----

However, upon compiling, ifort gives the following message:

===
fortcom: Error: test_conf.f90, line 7: The shapes of the array
expressions do not conform.
print *, a(2:) /= ' ' .OR. a(1:) /= ' '
----------------------^
compilation aborted for test_conf.f90 (code 1)
===

g95 gives:

===
In file test_conf.f90:7

print *, a(2:) /= ' ' .OR. a(1:) /= ' '
1
Error: .OR. operation at (1) has different shape on dimension 1 (29/30)
===

lf95 (Lahey) gives:

===
2105-S: "test_conf.f90", line 7, column 23: In elemental binary
operations two operands must conform in shape.
Encountered 1 error, 0 warnings in file test_conf.f90.
===

Please compile test_conf with CVF, post the result (if you will not, I'm
sure others will), and then explain why CVF is 'not happy'. Hint: you
should be able to figure out what the problem is by reading the error
messages. If you contend that this example code is not using the same
non-standard construct that I criticize in your code above, please
explain why in full detail.

As an interesting aside, I compiled the same test program with a as an
allocatable(:) array. No compiler complained at compile time, and *only*
Lahey lf95 threw a runtime error, *if* I compiled with array expression
shape checking. It looks like ifort and g95 would benefit from the same
functionality.

Of course, whether the compilers were or were not able to catch the bug
has essentially no bearing on whether the bug violates the standard or not.

cheers,

Rich

Rich Townsend

2005-08-22, 7:02 pm

David Frank wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...
>
>
>
>
> The "results of the two compares cannot be .OR.ed to each other" ?????
>
> Thats not happening, when pack sees the first test for a char existing
> which happens 5x more frequently than the
> OPTIONAL 2nd test involving the previous char, it immediately packs the
> char and MOVES ON,
> BECAUSE its a OR not a AND

..OR. does not short circuit in Fortran; that is, in the expression "a
..OR. b" there is no guarantee of order of evaluation, or that the
evaluation of one operand will be bypassed if the other is .TRUE..

This is pretty elementary stuff. I really am amazed you didn't know this.

cheers,

Rich

David Frank

2005-08-22, 7:02 pm

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:decir6$i2n$1@scrotar.nss.udel.edu...
> David Frank wrote:

>
> .OR. does not short circuit in Fortran; that is, in the expression "a .OR.
> b" there is no guarantee of order of evaluation, or that the evaluation of
> one operand will be bypassed if the other is .TRUE..
>
> This is pretty elementary stuff. I really am amazed you didn't know this.
>

As I am amazed you dont know a optimizing compiler would be left at the gate
if it evaluated all of a
multi-clause OR before deciding that one of the OR conditions had been
triggered back upstream.

Rich Townsend

2005-08-22, 7:02 pm

David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:decir6$i2n$1@scrotar.nss.udel.edu...
>
>
>
>
>
> As I am amazed you dont know a optimizing compiler would be left at the gate
> if it evaluated all of a
> multi-clause OR before deciding that one of the OR conditions had been
> triggered back upstream.

And I'd be flabbergasted that you are so outrageously ignorant of
Fortran, that you fail to understand that such short circuiting is not
guaranteed by the standard, and is therefore wholly non-portable. Hell,
this is one of the topics in Fortran Common Pitfalls; see

http://www.ibiblio.org/pub/language...n/ch1-8.html#12

I see that you've dodged my challenge to compile test_conf using CVF?
Well, I have another challenge. I want your to recode your 3-line blank
reduction code, but with the order of the operands in the .OR.
expression reversed. I then want you to recompile with bounds checking
enabled, and see what happens.

cheers,

Rich

Dick Hendrickson

2005-08-22, 7:02 pm

David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:decir6$i2n$1@scrotar.nss.udel.edu...
>
>
>
>
>
> As I am amazed you dont know a optimizing compiler would be left at the gate
> if it evaluated all of a
> multi-clause OR before deciding that one of the OR conditions had been
> triggered back upstream.
>
>
That's really very hardware dependent. On old Cray-like
machines, jumps are very expensive in clock cycles
(10 or so cycles for the not taken case, more if the jump
is taken and the target is far away) and logical compares
take a cycle or two and multiple compares can be made at the
same time. If the AND and OR terms are relatively simple,
it's by far the winning strategy to do all of them and then
do one test. On some machines, short-circuiting is a
DISoptimization, on others, it depends on the context.
Multiple branches that are forward or backward or out
of the loop will have different effects on pipelining.

Dick Hendrickson

Richard E Maine

2005-08-22, 7:02 pm

In article
<fhnOe.124084$5N3.116128@bgtnsc05-news.ops.worldnet.att.net>,
Dick Hendrickson <dick.hendrickson@att.net> wrote:

> On some machines, short-circuiting is a
> DISoptimization, on others, it depends on the context.

And there have existed compilers that short circuited *BACKWARDS*,
evaluating conditions on the right side first, skipping the left ones
depending on the results from the right. I'd swear I recalled that in
some predecessor of DF's current one and only compiler, but I couldn't
cite particular versions without research.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

David Frank

2005-08-22, 7:02 pm

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:decncu$jds$1@scrotar.nss.udel.edu...
> David Frank wrote:
>
> I see that you've dodged my challenge to compile test_conf using CVF?

No point, you ignore my admission that CVF has a bug and choose to browbeat
me.
My reduce_blanks function has been modified for a(1:len(line)-1) and
strings.f90 has been updated with this mod.

> Well, I have another challenge. I want your to recode your 3-line blank
> reduction code, but with the order of the operands in the .OR. expression
> reversed.

OK, I also expanded the line to contain a b c d e ..... x y z

My routine (see source posted for Glen Hermannsfeldt) has identical timings
swapping the OR components,
of 1.03 sec vs. 1.06 sec for Giles OPAQUE mask setting version.

>I then want you to recompile with bounds checking enabled, and see what
>happens

NO, that requires using the IDE and I am strictly command line user these
days.
You cant justify your request for bounds checking as THERE IS NO WAY there
can be a fault.
as I have pointed out elsewhere MORE THAN ONCE.

Rich Townsend

2005-08-22, 7:02 pm

David Frank wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:decncu$jds$1@scrotar.nss.udel.edu...
>
>
>
> No point, you ignore my admission that CVF has a bug and choose to browbeat
> me.

Where is your admission? I can't see it anywhere in these newsgroups.

> My reduce_blanks function has been modified for a(1:len(line)-1) and
> strings.f90 has been updated with this mod.
>
>
>
>
> OK, I also expanded the line to contain a b c d e ..... x y z
>
> My routine (see source posted for Glen Hermannsfeldt) has identical timings
> swapping the OR components,
> of 1.03 sec vs. 1.06 sec for Giles OPAQUE mask setting version.
>
>
>
>
> NO, that requires using the IDE and I am strictly command line user these
> days.

Funny, I have had no problem switching on bounds checking from the
command line in the following compilers I have used:

Lahey lf95 Express for Linux
g77
g95
Intel ifort for Linux
Compaq f95 for Tru/64
NAG f95 for Linux
Sun f95 for Solaris

Can an independent third party confirm that CVF has no way of enabling
bounds checking from the command line? Or is DF simply lying?

> You cant justify your request for bounds checking as THERE IS NO WAY there
> can be a fault.
> as I have pointed out elsewhere MORE THAN ONCE.

Why, then, does the Intel compiler throw the following error:

--
forrtl: severe (408): fort: (2): Subscript #1 of the array A has value
31 which is greater than the upper bound of 30
--

....when I compile the following code with bounds checking enabled:

--
program test_conf_alloc

character(1), dimension(:), allocatable :: a

allocate(a(30))

a = TRANSFER(' The quick brown fox ', ' ')

print *, a(1:) /= ' ' .OR. a(2:) /= ' '

end program test_conf_alloc
--

Looks like a bounds violation to me. Hell, I don't even need a compiler
to tell me that; a(1:) and a(:2) are clearly not conformable. However, I
would appreciate it if someone could perform the same test using CVF.

cheers,

Rich

David Frank

2005-08-22, 7:02 pm

"Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
news:fhnOe.124084$5N3.116128@bgtnsc05-news.ops.worldnet.att.net...
>
>
> That's really very hardware dependent. On old Cray-like
> machines, jumps are very expensive in clock cycles
> (10 or so cycles for the not taken case, more if the jump
> is taken and the target is far away) and logical compares
> take a cycle or two and multiple compares can be made at the
> same time. If the AND and OR terms are relatively simple,
> it's by far the winning strategy to do all of them and then
> do one test. On some machines, short-circuiting is a
> DISoptimization, on others, it depends on the context.
> Multiple branches that are forward or backward or out
> of the loop will have different effects on pipelining.
>
> Dick Hendrickson
>

I usually agree with you, but above dont compute.

CVF (optimize or not) sez its going to make a multi-or test and JUMP
immediately after each test.

e.g. below generated for SIMPLE logic and the winning strategy is to JUMP
if (x == 1.or.y ==2 .or. z == 3) stop

stop is the label $0010 in below assy.

fld dword ptr .bss$+12 ; 000007
fcomp dword ptr .literal$+12
mov eax, 0
fnstsw ax
test ah, 68
jpo lab$0010 < jump
fld dword ptr .bss$+4
fcomp dword ptr .literal$+8
mov eax, 0
fnstsw ax
test ah, 68
jpo lab$0010 < jump
fld dword ptr .bss$+8
fcomp dword ptr .literal$+4
mov eax, 0
fnstsw ax
test ah, 68
jpo lab$0010 < jump

I would bet something similar would happen with ANY compiler.
This supports my intuition a compiler is NOT going to plow thru all code on
a OR,
(at least CVF doesnt)..

glen herrmannsfeldt

2005-08-22, 7:02 pm

David Frank wrote:
> "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
> news:fhnOe.124084$5N3.116128@bgtnsc05-news.ops.worldnet.att.net...

(snip)
[color=darkred]
> CVF (optimize or not) sez its going to make a multi-or test and JUMP
> immediately after each test.

Newer intel processors have the conditional load instruction
that can be used instead of a branch around a load. That saves
any delay due to the branch. Most compilers still don't
generate it to maintain compatibility with older processors.

Branch prediction helps, but isn't perfect.

-- glen

James Giles

2005-08-22, 7:02 pm

David Frank wrote:
> "James Giles" <jamesgiles@worldnet.att.net> wrote in message
> news:OH5Oe.121413$5N3.26702@bgtnsc05-news.ops.worldnet.att.net...
>
>
> The "results of the two compares cannot be .OR.ed to each other"
> ?????
>
> Thats not happening, when pack sees the first test for a char
> existing which happens 5x more frequently than the
> OPTIONAL 2nd test involving the previous char

Bullshit. .OR. in Fortran is commutative. The compiler is
free to reference in either order. And shortcutting is often
slower than just doing the operations straight through (jumps
cost too). Unless you have direct evidence that a compiler
actually *does* shortcutting, you're talking through your ---.

And, that's still not relevant to the point I made: THE EXPRESSION
IS ILLEGAL!!!!!!!

(By the way, I looked at the assembly code generated by
DF's procedure. Using CVF6.6c from the command line with
no options. It does *NOT* short-circuit the OR. It unrolls
the loop five times and does some other creative stuff, but
no short-circuiting. It definitely compares each element of
the input string to blank *twice* (except the first and last).)

> , it immediately
> packs the char and MOVES ON,
> BECAUSE its a OR not a AND

AND vs. OR is irrelevant since the compiler knows DeMorgan's
rules just as well as I do. Though, apparently you don't. If there's
anything to gain by short-circuiting the OR, then AND could also
be shortcircuited under the same conditions. What would you now
be irrelevantly complaining about if I'd used OR?

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

David Frank

2005-08-22, 7:02 pm

"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:CeqOe.654652$cg1.157674@bgtnsc04-news.ops.worldnet.att.net...
> David Frank wrote:
> Unless you have direct evidence that a compiler
> actually *does* shortcutting, you're talking through your ---.

see: my reply to Dick Hendrickson

James Van Buskirk

2005-08-22, 7:02 pm

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:ded8jo$o9d$1@scrotar.nss.udel.edu...

> Can an independent third party confirm that CVF has no way of enabling
> bounds checking from the command line? Or is DF simply lying?

C:\Program Files\Microsoft Visual Studio\James\clf\bounds_1>type
bounds_1.f90
program test_conf_alloc

character(1), dimension(:), allocatable :: a

allocate(a(30))

a = TRANSFER(' The quick brown fox ', ' ')

print *, a(1:) /= ' ' .OR. a(2:) /= ' '

end program test_conf_alloc

C:\Program Files\Microsoft Visual Studio\James\clf\bounds_1>df /check:bounds
/tr
aceback bounds_1
Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C)
Copyright 2003 Compaq Computer Corp. All rights reserved.

bounds_1
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/subsystem:console
/entry:mainCRTStartup
/debugtype:cv
/pdb:none
C:\DOCUME~1\James\LOCALS~1\Temp\obj1A.tmp
dfor.lib
libc.lib
dfconsol.lib
dfport.lib
kernel32.lib
/out:bounds_1.exe
/incremental:no

C:\Program Files\Microsoft Visual Studio\James\clf\bounds_1>bounds_1
forrtl: severe (161): Program Exception - array bounds exceeded
Image PC Routine Line Source
bounds_1.exe 00401454 TEST_CONF_ALLOC 9 bounds_1.F90
bounds_1.exe 00426A49 Unknown Unknown Unknown
bounds_1.exe 0041DD84 Unknown Unknown Unknown
KERNEL32.dll 7C59893D Unknown Unknown Unknown

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

James Van Buskirk

2005-08-22, 7:02 pm

"David Frank" <dave_frank@hotmail.com> wrote in message
news:8DpOe.271$_84.4@newsread1.news.atl.earthlink.net...

> CVF (optimize or not) sez its going to make a multi-or test and JUMP
> immediately after each test.

A:\>type *.*

cmov_1.asm

.set noat
.set noreorder
.data
.align 0
.lcomm .T4_ 1
.lcomm fill$$1 7
.lcomm I 4
.lcomm .T2_ 4
.rdata
.align 0
$$1:
.long 0x3F800000 # .float 1.000000
.long 0x40A00000 # .float 5.000000
.byte 0 : 8
.section .drectve$1 ".drectve" LNK_INFO LNK_REMOVE
$$2:
.ascii "-defaultlib:dfor.lib "

.ascii "-defaultlib:libc.lib "

.ascii "-defaultlib:dfconsol.lib "

.ascii "-defaultlib:dfport.lib "

.ascii "-defaultlib:kernel32.lib "

.byte 0 : 13
.text
.arch ev56
.align 4
.file 1 "H:\program files\Microsoft Visual
Studio\James\cmov_1\cmov_1.f90"
.loc 1 1
# 1 function cmov_1(x,n)
.globl CMOV_1
.ent CMOV_1
.eflag 1
.loc 1 1
CMOV_1:
.loc 1 11
# 2 implicit none
# 3 integer, intent(in) :: n
# 4 real, intent(in) :: x(n)
# 5 integer cmov_1
# 6 integer i
# 7 real y
# 8 real next_y
# 9
# 10 y = 0
# 11 do i = 1, n
ldl $17, ($17)
# 000011
.loc 1 1
lda $sp, -16($sp)
# 000001
.frame $sp, 16, $26
.prologue 0
.loc 1 10
fclr $f0
# 000010
unop
.loc 1 13
# 12 next_y = y+1
# 13 if(x(i) > 5) y = next_y
ldah $28, $$1($31)!refhi!1
# 000013
.loc 1 11
clr $1
# 000011
ble $17, lab$0006
cmovle $17, 1, $17
.loc 1 13
lds $f1, $$1+4($28)!reflo!1
# 000013
.loc 1 12
ldah $28, $$1($31)!refhi!2
# 000012
lds $f10, $$1($28)!reflo!2
.loc 1 11
mov $17, $2
# 000011
cmple $17, 3, $3
bne $3, L$11
.loc 1 13
ldl $31, 140($16)
# 000013
.loc 1 11
lda $2, -4($17)
# 000011
cmple $2, 3, $5
.loc 1 14
# 14 end do
bne $5, L$6
# 000014
.loc 1 11
L$8:
# 000011
unop
unop
unop
unop
.loc 1 13
lds $f11, ($16)
# 000013
cmptle $f11, $f1, $f11
.loc 1 12
adds $f0, $f10, $f12
# 000012
.loc 1 13
lds $f13, 4($16)
# 000013
cmptle $f13, $f1, $f13
unop
fcmoveq $f11, $f12, $f0
lds $f15, 8($16)
cmptle $f15, $f1, $f15
.loc 1 12
adds $f0, $f10, $f14
# 000012
.loc 1 13
lds $f17, 12($16)
# 000013
cmptle $f17, $f1, $f17
fcmoveq $f13, $f14, $f0
.loc 1 12
adds $f0, $f10, $f16
# 000012
.loc 1 13
ldl $31, 156($16)
# 000013
.loc 1 11
lda $2, -4($2)
# 000011
lda $1, 4($1)
.loc 1 13
lda $16, 16($16)
# 000013
.loc 1 11
cmple $2, 3, $20
# 000011
.loc 1 13
fcmoveq $f15, $f16, $f0
# 000013
.loc 1 12
adds $f0, $f10, $f18
# 000012
unop
.loc 1 13
fcmoveq $f17, $f18, $f0
# 000013
.loc 1 14
beq $20, L$8
# 000014
.loc 1 11
L$6:
# 000011
.loc 1 13
lds $f19, ($16)
# 000013
unop
lds $f21, 4($16)
lds $f23, 8($16)
unop
unop
cmptle $f19, $f1, $f19
lds $f25, 12($16)
.loc 1 11
lda $1, 4($1)
# 000011
unop
.loc 1 13
cmptle $f21, $f1, $f21
# 000013
.loc 1 11
lda $16, 16($16)
# 000011
.loc 1 12
adds $f0, $f10, $f20
# 000012
.loc 1 13
cmptle $f23, $f1, $f23
# 000013
cmptle $f25, $f1, $f25
fcmoveq $f19, $f20, $f0
.loc 1 12
adds $f0, $f10, $f22
# 000012
.loc 1 13
fcmoveq $f21, $f22, $f0
# 000013
.loc 1 12
adds $f0, $f10, $f24
# 000012
.loc 1 13
fcmoveq $f23, $f24, $f0
# 000013
.loc 1 12
adds $f0, $f10, $f26
# 000012
unop
.loc 1 13
fcmoveq $f25, $f26, $f0
# 000013
.loc 1 11
ble $2, lab$0006
# 000011
unop
unop
L$11:
.loc 1 13
unop
unop
unop
unop
lds $f27, ($16)
.loc 1 12
adds $f0, $f10, $f28
# 000012
.loc 1 11
lda $2, -1($2)
# 000011
unop
lda $1, 1($1)
lda $16, 4($16)
.loc 1 13
cmptle $f27, $f1, $f27
# 000013
unop
fcmoveq $f27, $f28, $f0
.loc 1 11
bgt $2, L$11
# 000011
.loc 1 14
lab$0006:
# 000014
.loc 1 15
# 15 cmov_1 = y
cvttqc $f0, $f0
# 000015
stt $f0, ($sp)
xor $sp, $31, $sp
ldl $0, ($sp)
.loc 1 1
.loc 1 16
# 16 end function cmov_1
lda $sp, 16($sp)
# 000016
ret ($26)
.loc 1 1
.end CMOV_1

cmov_1.f90

function cmov_1(x,n)
implicit none
integer, intent(in) :: n
real, intent(in) :: x(n)
integer cmov_1
integer i
real y
real next_y

y = 0
do i = 1, n
next_y = y+1
if(x(i) > 5) y = next_y
end do
cmov_1 = y
end function cmov_1

I call the reader's attention to the cmptle/fcmoveq combinations
that CVF6.5A assembles to handle the IF statement in the loop.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Rich Townsend

2005-08-22, 7:02 pm

James Van Buskirk wrote:
> "Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
> news:ded8jo$o9d$1@scrotar.nss.udel.edu...
>
>
>
>
> C:\Program Files\Microsoft Visual Studio\James\clf\bounds_1>type
> bounds_1.f90
> program test_conf_alloc
>
> character(1), dimension(:), allocatable :: a
>
> allocate(a(30))
>
> a = TRANSFER(' The quick brown fox ', ' ')
>
> print *, a(1:) /= ' ' .OR. a(2:) /= ' '
>
> end program test_conf_alloc
>
> C:\Program Files\Microsoft Visual Studio\James\clf\bounds_1>df /check:bounds
> /tr
> aceback bounds_1
> Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C)
> Copyright 2003 Compaq Computer Corp. All rights reserved.
>
> bounds_1
> Microsoft (R) Incremental Linker Version 6.00.8447
> Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
>
> /subsystem:console
> /entry:mainCRTStartup
> /debugtype:cv
> /pdb:none
> C:\DOCUME~1\James\LOCALS~1\Temp\obj1A.tmp
> dfor.lib
> libc.lib
> dfconsol.lib
> dfport.lib
> kernel32.lib
> /out:bounds_1.exe
> /incremental:no
>
> C:\Program Files\Microsoft Visual Studio\James\clf\bounds_1>bounds_1
> forrtl: severe (161): Program Exception - array bounds exceeded
> Image PC Routine Line Source
> bounds_1.exe 00401454 TEST_CONF_ALLOC 9 bounds_1.F90
> bounds_1.exe 00426A49 Unknown Unknown Unknown
> bounds_1.exe 0041DD84 Unknown Unknown Unknown
> KERNEL32.dll 7C59893D Unknown Unknown Unknown
>

Thanks, James.

So it appears that DF was just bullshitting. Since he can't conduct an
argument without resorting to falsehood, I see little point in debating
him further.

cheers

Rich

Dick Hendrickson

2005-08-22, 9:57 pm

David Frank wrote:
> "Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
> news:fhnOe.124084$5N3.116128@bgtnsc05-news.ops.worldnet.att.net...
>
>
>
> I usually agree with you, but above dont compute.
>
Usually?????

> CVF (optimize or not) sez its going to make a multi-or test and JUMP
> immediately after each test.
>
> e.g. below generated for SIMPLE logic and the winning strategy is to JUMP
> if (x == 1.or.y ==2 .or. z == 3) stop
>

That's fine, I said it's hardware dependent and you've
shown one hardware's way to do it. The fact is that
on the Crays in the 70s and 80s the absolute best way to
do that case was
1 load,s1 x
2 load,s2 y
3 load,s3 z
4 set,s4 1
5 set,s5 2
6 set,s6 3
7 s1 = s1?s4 I forget the syntax, test x==1
8 s2 = s2?s5 y==2
9 s2 = s2?s1 y==2 .or. x==1
10 s3 = s3?46 z==3
11 s0 = s2?s3 z==3 .or. y==2 .or. x==1
12 jsz whatever

The three load instructions execute in parallel, the 3 set
of registers to constants happen in parallel with the loads
and in effect take 0 clock cycles.
variable x is in s1 at about clock period 16 (depends on
the model of the Cray in question) so instruction labeled
7 issues at clock period 16, instruction 8 issues at clock
period 18 (because the load instructions take 2 cp to issue)
instruction 9 issues at clock period 19 (logical
instructions on all Cray's were da*m fast). Instruction 10
issues at clock period 20, instruction 11 issues at cp 21.
the jump makes it's decision at about cp 25 (takes a while
for the logical result to get to the jump decision box).

If instead you do it as
1 load,s1 x
2 set,s2 1
3 s0 = s1?s2
4 jsz whatever

instruction 3 issues at clock period 16, instruction 3
at cp 17 and instruction 4 makes it's decision at cp 21.
In other words, NOT short-circuiting 3 decisions takes
4 more cp's that a simple one expression test and is about
50 clock periods shorter than three serial test-jump
sequences.

If you want to tell me the INTEL whatever is different
from the Cray's, I'll believe you. But, that is exactly my
point. It's hardware dependent. Each time Intel makes a
new chip, Steve orders someone to read the hardware manual
and then they bugger up the code generator. It's hardware
dependent.

Try replacing your simple line with
if(x(i) == 1 .or. y(i) ==2 .or. z(i)==3) stop
and put the line in a DO loop. Then, put it in a loop
where x, y, and z are calculated by some non-trivial
calculation (so that the compiler can't decide if x(i) == 1
at compile time). And then try them at different
optimizaion levels, including "brain-dead" and "turbo".
At least one of us will be surprised at the results ;).

Dick Hendrickson

Rich Townsend

2005-08-22, 9:57 pm

Dick Hendrickson wrote:
>
>
> David Frank wrote:
>
> Usually?????
>
>
> That's fine, I said it's hardware dependent and you've
> shown one hardware's way to do it. The fact is that
> on the Crays in the 70s and 80s the absolute best way to
> do that case was
> 1 load,s1 x
> 2 load,s2 y
> 3 load,s3 z
> 4 set,s4 1
> 5 set,s5 2
> 6 set,s6 3
> 7 s1 = s1?s4 I forget the syntax, test x==1
> 8 s2 = s2?s5 y==2
> 9 s2 = s2?s1 y==2 .or. x==1
> 10 s3 = s3?46 z==3
> 11 s0 = s2?s3 z==3 .or. y==2 .or. x==1
> 12 jsz whatever
>
> The three load instructions execute in parallel, the 3 set
> of registers to constants happen in parallel with the loads
> and in effect take 0 clock cycles.
> variable x is in s1 at about clock period 16 (depends on
> the model of the Cray in question) so instruction labeled
> 7 issues at clock period 16, instruction 8 issues at clock
> period 18 (because the load instructions take 2 cp to issue)
> instruction 9 issues at clock period 19 (logical
> instructions on all Cray's were da*m fast). Instruction 10
> issues at clock period 20, instruction 11 issues at cp 21.
> the jump makes it's decision at about cp 25 (takes a while
> for the logical result to get to the jump decision box).
>
> If instead you do it as
> 1 load,s1 x
> 2 set,s2 1
> 3 s0 = s1?s2
> 4 jsz whatever
>
> instruction 3 issues at clock period 16, instruction 3
> at cp 17 and instruction 4 makes it's decision at cp 21.
> In other words, NOT short-circuiting 3 decisions takes
> 4 more cp's that a simple one expression test and is about
> 50 clock periods shorter than three serial test-jump
> sequences.
>
> If you want to tell me the INTEL whatever is different
> from the Cray's, I'll believe you. But, that is exactly my
> point. It's hardware dependent. Each time Intel makes a
> new chip, Steve orders someone to read the hardware manual
> and then they bugger up the code generator. It's hardware
> dependent.
>
> Try replacing your simple line with
> if(x(i) == 1 .or. y(i) ==2 .or. z(i)==3) stop
> and put the line in a DO loop.

To be faithful to the original example, you would have to make sure that
x, y and z don't have the same declared dimensions.

Then, put it in a loop
> where x, y, and z are calculated by some non-trivial
> calculation (so that the compiler can't decide if x(i) == 1
> at compile time). And then try them at different
> optimizaion levels, including "brain-dead" and "turbo".
> At least one of us will be surprised at the results ;).
>
> Dick Hendrickson
>

robin

2005-08-22, 9:57 pm

David Frank wrote in message
<2KWNe.9300$ns.4466@newsread1.news.atl.earthlink.net>...

>In any case, your next message (also cross-posted BY YOU from
>comp.lang.pl1) shows my insightful 2char test

"insightful" ? You do mean your illegal Fortran code below?

> (that Giles and everyone
>overlooked and is source of his pique) adapts to array syntax and is
>imbedded into
>
> outline = line(1:1) // Copy( PACK(a(2:), a(2:) /= ' ' .OR. a(1:) /= ' ',
pad) )

robin

2005-08-22, 9:57 pm

James J. Weinkam wrote in message ...
>robin wrote:
>This won't work as you intend. Even after you fix the missing parenthesis
>error, the statement will raise the ERROR condition and the value of COUNT at
>that point will be one too large.

ON ERROR PUT (COUNT);

is required to display the result.

robin

2005-08-22, 9:57 pm

David Frank wrote in message
<0gpOe.134$9i4.16@newsread2.news.atl.earthlink.net>...
>
>"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
>news:decncu$jds$1@scrotar.nss.udel.edu...
>
>No point, you ignore my admission that CVF has a bug

First you said that you couldn't enable subscript checking;
now you say the coompiler has a bug.
Whjat are we to believe?

The reality is that you code is in error.

>You cant justify your request for bounds checking as THERE IS NO WAY there
>can be a fault.
>as I have pointed out elsewhere MORE THAN ONCE.

Your code is FAULTY.

David Frank

2005-08-23, 7:57 am

"Dick Hendrickson" <dick.hendrickson@att.net> wrote in message
news:ZQtOe.655702$cg1.334601@bgtnsc04-news.ops.worldnet.att.net...
>

< snip > Nice example from the parallel processing world
I guess the logic doing it that way is "we gotta keep these parallel
processing units busy"
[color=darkred]
> Try replacing your simple line with
> if(x(i) == 1 .or. y(i) ==2 .or. z(i)==3) stop
> and put the line in a DO loop. Then, put it in a loop
> where x, y, and z are calculated by some non-trivial
> calculation (so that the compiler can't decide if x(i) == 1
> at compile time). And then try them at different
> optimizaion levels, including "brain-dead" and "turbo".
> At least one of us will be surprised at the results ;).
>

I am not surprised at results below...

program or_jump
real :: x(3,2)
do n = 1,2
call random_number(x)
if (x(1,n) == 1 .or. x(2,n) == 2 .or. x(3,n) == 3) stop
end do
end program

pertinent excerpts with blank line(s) inserted for identification

fld dword ptr [ecx] ; 000008
fcomp dword ptr .literal$+12
fnstsw ax
test ah, 68
jpo lab$0017

mov eax, 0
fld dword ptr -8[ebx]
fcomp dword ptr .literal$+8
fnstsw ax
test ah, 68
jpo lab$0017

mov esi, dword ptr -8[ebp]
mov eax, 0
fld dword ptr -4[esi]
fcomp dword ptr .literal$+4
fnstsw ax
test ah, 68
jpo lab$0017

robin

2005-08-24, 3:57 am

David Frank wrote in message ...
>OK, when I was experimenting using my PACK syntax in a test program
>suddenly CVF got unhappy with the identical PACK syntax that was acceptable
>in my strings.f90 file..
>So I am WRONG, acceptance is NOT assured and I have updated my
>REDUCE_BLANKS function in
>
> http://home.earthlink.net/~dave_gemini/strings.f90
>
>accordingly to use PACK ( a(2:), a(2:) /= ' ' .OR. a(1:LEN(LINE)-1) /=
>' '), pad )
>
>This is a CVF bug,

Whether or not is irrelevant.
What's relevant is that there's a bug in your code.

>also noted is removing the -1 from the LEN(LINE) also made it accept the
>statement in my test program.

That would introduce another bug into your program.

David Frank

2005-08-24, 3:57 am

"robin" <robin_v@bigpond.com> wrote in message
news:mESOe.8631$FA3.7614@news-server.bigpond.net.au...
>
> David Frank wrote in message ...
>
> Whether or not is irrelevant.
> What's relevant is that there's a bug in your code.
>
>
>
> That would introduce another bug into your program.
>
>

Read what RM has to say (I'm not going to quote him)..
I already stated the driver index is PACK's array arg not the arrays
associated with the logical mask.
As long as the logical arrays are >= PACK array size,
THERE WILL BE NO PROBLEM, NO BOUNDS FAULT, NADA..

The problem is CVF sporatically wants to diagnose the logical array sizes
for being unequal with each other and the array being packed.
I never encountered wrong answers because I never supplied logical arrays
that were less than the size of the array being PACKED.

However I dont expect you or Rich Townsend will ever grasp how PACK works.

And your claim today posted in comp.lang.pl1 that you have written a PL/I
PACK is ridiculous, you have no regard for the truth..

robin

2005-08-24, 7:56 am

David Frank wrote in message ...
>
>"robin" <robin_v@bigpond.com> wrote in message
>news:mESOe.8631$FA3.7614@news-server.bigpond.net.au...
'), pad )[color=darkred]
[color=darkred]
>
>Read what RM has to say (I'm not going to quote him)..
>I already stated the driver index is PACK's array arg not the arrays
>associated with the logical mask.
>As long as the logical arrays are >= PACK array size,
>THERE WILL BE NO PROBLEM, NO BOUNDS FAULT, NADA..

You would have incompatible array expressions, one having bounds 2 thru
len(line)
and the other having bounds 1 thru len(line), and that's a programming error.

>The problem is CVF sporatically wants to diagnose the logical array sizes
>for being unequal with each other and the array being packed.

Then it is correctly diagnosing that the arrays have
an unequal number of elements.

>I never encountered wrong answers because I never supplied logical arrays
>that were less than the size of the array being PACKED.

That's irrelevant. The array sub-espressions have to be ORed first,
and to do that, the arrays are required to have EXACTLY the same number of
elements.

>However I dont expect you or Rich Townsend will ever grasp how PACK works.
>
>And your claim today posted in comp.lang.pl1 that you have written a PL/I
>PACK is ridiculous, you have no regard for the truth..

The truth is that they have been written.

James Giles

2005-08-24, 6:59 pm

David Frank wrote:
....
> Read what RM has to say (I'm not going to quote him)..
> I already stated the driver index is PACK's array arg not the arrays
> associated with the logical mask.

There is no such thing as a "driver index" in PACK.
It requires properly formed arrays as its arguments.
It then (using whatever method an implementation
chooses - even complete parallel operation, if
the hardware supports it) achieves the requires
semantics.

In your code, there was no properly formed array
mask argument passed. The expression was non
standard.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Sponsored Links