Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB-Alt <bohannonindustriesllc@gmail.com>
Newsgroups: comp.arch
Subject: Re: "Mini" tags to reduce the number of op codes
Date: Thu, 4 Apr 2024 17:28:43 -0500
Organization: A noiseless patient Spider
Lines: 129
Message-ID: <uun9is$tpk9$1@dont-email.me>
References: <uuk100$inj$1@dont-email.me> <uukduu$4o4p$1@dont-email.me>
 <420556afacf3ef3eea07b95498bcbef0@www.novabbs.org>
 <uulojh$honc$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 04 Apr 2024 22:28:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b6c0ef59d3cbba2f2dcb16f34c8f843d";
	logging-data="976521"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/80E6LBM+lpcA+mR80cZ1PWpXPYiICAZg="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ArRAneYNpiG2SmKH8VMcPoZozY4=
Content-Language: en-US
In-Reply-To: <uulojh$honc$1@dont-email.me>
Bytes: 7557

On 4/4/2024 3:32 AM, Terje Mathisen wrote:
> MitchAlsup1 wrote:
>> BGB-Alt wrote:
>>
>>> On 4/3/2024 11:43 AM, Stephen Fuld wrote:
>>>> There has been discussion here about the benefits of reducing the 
>>>> number of op codes.  One reason not mentioned before is if you have 
>>>> fixed length instructions, you may want to leave as many codes as 
>>>> possible available for future use.  Of course, if you are doing a 
>>>> 16-bit instruction design, where instruction bits are especially 
>>>> tight, you may save enough op-codes to save a bit, perhaps allowing 
>>>> a larger register specifier field, or to allow more instructions in 
>>>> the smaller subset.
>>>>
>>>> It is in this spirit that I had an idea, partially inspired by 
>>>> Mill’s use of tags in registers, but not memory.  I worked through 
>>>> this idea using the My 6600 as an example “substrate” for two 
>>>> reasons.  First, it 
>>                 66000
>>>> has several features that are “friendly” to the idea.  Second, I 
>>>> know Mitch cares about keeping the number of op codes low.
>>>>
>>>> Please bear in mind that this is just the germ of an idea.  It is 
>>>> certainly not fully worked out.  I present it here to stimulate 
>>>> discussions, and because it has been fun to think about.
>>>>
>>>> The idea is to add 32 bits to the processor state, one per register 
>>>> (though probably not physically part of the register file) as a tag. 
>>>> If set, the bit indicates that the corresponding register contains a 
>>>> floating-point value.  Clear indicates not floating point (integer, 
>>>> address, etc.).  There would be two additional instructions, load 
>>>> single floating and load double floating, which work the same as the 
>>>> other 32- and 64-bit loads, but in addition to loading the value, 
>>>> set the tag bit for the destination register.  Non-floating-point 
>>>> loads would clear the tag bit.  As I show below, I don’t think you 
>>>> need any special "store tag" instructions.
>>
>> What do you do when you want a FP bit pattern interpreted as an 
>> integer, or vice versa.
> 
> This is why, if you want to copy Mill, you have to do it properly:
> 
> Mill does NOT care about the type of data loaded into a particular belt 
> slot, only the size and if it is a scalar or a vector filling up the 
> full belt slot. In either case you will also have marker bits for 
> special types like None and NaR.
> 
> So scalar 8/16/32/64/128 and vector 8x16/16x8/32x4/64x2/128x1 (with the 
> last being the same as the scalar anyway).
> 
> Only load ops and explicit widening/narrowing ops sets the size tag 
> bits, from that point any op where it makes sense will do the right 
> thing for either a scalar or a short vector, so you can add 16+16 8-bit 
> vars with the same ADD encoding as you would use for a single 64-bit ADD.
> 
> We do NOT make any attempt to interpret the actual bit patterns sotred 
> within each belt slot, that is up to the instructions. This means that 
> there is no difference between loading a float or an int32_t, it also 
> means that it is perfectly legel (and supported) to use bit operations 
> on a FP variable. This can be very useful, not just to fake exact 
> arithmetic by splitting a double into two 26-bit mantissa parts:
> 

I guess useful to know.

Haven't heard much about Mill in a while, so don't know what if any 
progress is being made.


As I can note, in my actual ISA, any type-tagging in the registers was 
explicit and opt-in, generally managed by the compiler/runtime/etc; in 
this case, the ISA merely providing facilities to assist with this.


The main exception would likely have been the possible "Bounds Check 
Enforce" mode, which would still need a bit of work to implement, and is 
not likely to be terribly useful. Most complicated and expensive parts 
are that it will require implicit register and memory tagging (to flag 
capabilities). Though, cheaper option is simply to not enable it, in 
which case things either behave as before, with the new functionality 
essentially being NOP. Much of the work still needed on this would be 
getting the 128-bit ABI working, and adding some new tweaks to the ABI 
to play well with the capability addressing (effectively it requires 
partly reworking how global variables are accessed).


The type-tagging scheme used in my case is very similar to that used in 
my previous BGBScript VMs (where, as I can note, BGBCC was itself a fork 
off of an early version of the BGBScript VM, and effectively using a lax 
hybrid typesystem masquerading as C). Though, it has long since moved to 
a more proper C style typesystem, with dynamic types more as an optional 
extension.


But, as can be noted, since dynamic typing is implemented via runtime 
calls, it is slower than the use of static types. But, this is likely to 
be unavoidable with any kind of conventional-ish architecture (and, some 
structures, like bounded array objects and ex-nihilo objects, are 
difficult to make performance competitive with bare pointers and structs).

Though, it is not so much that I think it is justifiable to forbid their 
existence entirely (as is more the philosophy in many strict static 
languages), or to mandate that programs roll their own (as typical in C 
and C++ land). Where, with compiler and runtime support, it is possible 
to provide them in ways that are higher performance than a plain C 
implementation.

Well, and also the annoyance that seemingly every dynamic-language VM 
takes a different approach to the implementation of its dynamic 
typesystem (along with language differences, ...).

For example, Common Lisp is very different from Smalltalk, despite both 
being categorically similar in this sense (or, versus Python, or versus 
JavaScript, or, ...). Not likely viable to address all of them in the 
same runtime (and would likely result in a typesystem that doesn't 
really match with any of them, ...).


Though, annoyingly, there are not really any mainstream languages in the 
"hybrid" category (say, in the gray area between C and ActionScript). 
And, then it ends up being a question of which is better in a choice 
between C with AS-like features, or "like AS but with C features".

So, alas...


> Terje
>