Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Concertlina II: Full Circle
Date: Tue, 18 Jun 2024 23:53:32 +0000
Organization: Rocksolid Light
Message-ID: <51b2ff96c5930444a0998d6a053a386c@www.novabbs.org>
References: <mas07jhu9i876gsov2gh8tap17kem5n21p@4ax.com> <132536f47d1b160ad3ad0340fc479c1d@www.novabbs.org> <v4c17j5eo503i93fb7imjpom5jqs3oivtv@4ax.com> <50c85586e1aec0eef53e83cef7cb1d5d@www.novabbs.org> <4mb37jdb25571s1q1pjlc3ludaaks7tukr@4ax.com> <e4c37jd4l9spbi5b23b525unp9p60ird8q@4ax.com> <v4sbut$1e75s$1@dont-email.me> <u8n37jt3o6smk5nbgrerfd31tcopk1ikkq@4ax.com> <v4sns0$1gk57$2@dont-email.me> <v4t2gn$1ipeh$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="436134"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Site: $2y$10$Ln8vtMI4amyK8hbQVvMVR.TTnzUlGGJaPXM3LxHZfsFDL1dEBMecC
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
Bytes: 2517
Lines: 36

Stephen Fuld wrote:

> Thomas Koenig wrote:

>> John Savard <quadibloc@servername.invalid> schrieb:
>> > On Tue, 18 Jun 2024 16:17:33 -0000 (UTC), Thomas Koenig
>> ><tkoenig@netcologne.de> wrote:
>> >>John Savard <quadibloc@servername.invalid> schrieb:
>> > 
>> >>> Also, this looping instruction is strictly a way to directly
>> encode >>> the FORTRAN DO loop. It does not attempt any vectorization.
>> > 
>> > > Which one, the FORTRAN 66 one or the one since FORTRAN 77?
>> 
>> > FORTRAN IV (or 66) indeed.
>> 
>> It was actually not defined in the standard, in practice it
>> was usually implemented by a test at the bottom of the loop,
>> and programs depended on that.
>> 
>> FORTRAN 77 fixed that, so now
>> 
>> 	DO 100 I=1,0
>> 
>> ...
>>   100   CONTINUE
>> 
>> is executed zero times.


> How does VVM handle that?  It sems you must "waste" some time, not
> executing the loop body until the furst LOOP instruction tells you
> whether to or not, or perhaps not actually updating the values the
> first time through the loop.  Neither seems optimal.  :-(

There is a check at the top of the loop which branches around the
VEC--LOOP bookends--most common loops get this optimized away.