From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from duke.felloff.net ([216.126.196.34]) by ewsd; Tue Jun 18 07:41:46 EDT 2019
Message-ID: <654BBA391790D2F7C6B12E5F673EE195@felloff.net>
Date: Tue, 18 Jun 2019 13:41:37 +0200
From: cinap_lenrek@felloff.net
To: 9front@9front.org
Subject: Re: [9front] Start Syncing Compilers with Plan 9
In-Reply-To: 8FCE1A8D8D8B792BBF325E9251A383C1@eigenstate.org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: ORM over XML blockchain STM solution 

ok, i tried the OINDEX change in a vm and ran into the issue
that 8c then runs out of registers compiling a chain of []
operations (libvorbis).

the reason is the following code in xcom(), which converts
addition with indirect operands into a index operation.
having side() return 1 for OINDE gated that bug.

the issue is that when the index operand is a name or
constant, its complex number (#reg) is zero which we
would propagate to the INDEX operation itself. but we
need at least ONE index register!

adjusting the #reg at just like at the brk: in xcom() fixes
the issue.

		if(n->addable == 8 && !side(n)) {
			indx(n);
			l = new1(OINDEX, idx.basetree, idx.regtree);
			l->scale = idx.scale;
			l->addable = 9;
			l->complex = l->right->complex;
+			if(l->complex == 0)
+				l->complex++;
			l->type = l->left->type;
			n->op = OADDR;
			n->left = l;
			n->right = Z;
			n->addable = 8;
			break;
		}

commited in:

changeset:   7276:0e16ecb295ad
parent:      7272:648786a6af71
user:        cinap_lenrek@felloff.net
date:        Tue Jun 18 13:28:15 2019 +0200
summary:     8c, 6c: fix INDEX node #reg calculation

--
cinap