Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Stephen Fuld Newsgroups: comp.arch Subject: Re: "Mini" tags to reduce the number of op codes Date: Tue, 16 Apr 2024 15:06:48 -0700 Organization: A noiseless patient Spider Lines: 67 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 17 Apr 2024 00:06:51 +0200 (CEST) Injection-Info: dont-email.me; posting-host="e4560d6e9e80920818ac28626eb60e90"; logging-data="873548"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ze8BLQS5Z2lyR4hGsbx4q111jtj1XrIs=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:5fpoTIeGdNc4O2/OfRrk4qeYJeI= Content-Language: en-US In-Reply-To: Bytes: 4049 On 4/3/2024 11:44 AM, EricP wrote: > 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 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. > > If you are adding a float/int data type flag you might as well > also add operand size for floats at least, though some ISA's > have both int32 and int64 ALU operations for result compatibility. Not needed for My 66000, as all floating point loads convert the loaded value to double precision. big snip > Currently the opcode data type can tell the uArch how to route > the  operands internally without knowing the data values. > For example, FPU reservation stations monitor float operands > and schedule for just the FPU FADD or FMUL units. > > Dynamic data typing would change that to be data dependent routing. > It means, for example, you can't begin to schedule a uOp > until you know all its operand types and opcode. Seems right. > > Looks like it makes such distributed decisions impossible. > Probably everything winds up in a big pile of logic in the center, > which might be problematic for those things whose complexity grows N^2. > Not sure how significant that is. Could be. Again, IANAHG. -- - Stephen Fuld (e-mail address disguised to prevent spam)