On 02/04/13 19:20, glen herrmannsfeldt wrote:> In comp.arch.fpga rickman <gnuarm@gmail.com> wrote: >> On 3/31/2013 2:34 PM, glen herrmannsfeldt wrote:>>> For Itanium, the different units do different things. There are >>> instruction formats that divide up the bits in different ways to make >>> optimal use of the bits. I used to have the manual nearby, but I don't >>> see it right now. > >> Yes, the array processor I worked on was coded from scratch, very >> laboriously. The Itanium is trying to run existing code as fast as >> possible. So they have a number of units to do similar things, but also >> different types, all working in parallel as much as possible. Also the >> parallelism in the array processor was all controlled by the programmer. >> In regular x86 processors the parallelism is controlled by the chip >> itself. I'm amazed sometimes at just how much they can get the chip to >> do, no wonder there are 100's of millions of transistors on the thing. >> I assume parallelism in the Itanium is back to the compiler smarts to >> control since it needs to be coded into the VLIW instructions. > > Seems to me that the big problem with the original Itanium was the > need to also run x86 code. That delayed the release for some time, and > in that time other processors had advanced. I believe that later > versions run x86 code in software emulation, maybe with some hardware > assist. >x86 compatibility was not the "big" problem with the Itanium (though it didn't help). There were two far bigger problems. One is that the chip was targeted as maximising throughput with little regard for power efficiency, since it was for the server market - so all of the logic was running all of the time to avoid latencies, and it has massive caches that run as fast as possible. The result here is that the original devices had a power density exceeding the core of a nuclear reactor (it was probably someone from AMD who worked that out...). The big problem, however, is that the idea with VLIW is that the compiler does all the work scheduling instructions in a way that lets them run in parallel. This works in some specialised cases - some DSP's have this sort of architecture, and some types of mathematical algorithms suit it well. But when Intel started work on the Itanium, compilers were not up to the task - Intel simply assumed they would work well enough by the time the chips were ready. Unfortunately for Intel, compiler technology never made it - and in fact, it will never work particularly well for general code. There are too many unpredictable branches and conditionals to predict parallelism at compile time. So most real-world Itanium code uses only about a quarter or so of the processing units in the cpu at any one time (though some types of code can work far better). Thus Itanium chips run at half the real-world speed of "normal" processors, while burning through at least twice the power.
MISC - Stack Based vs. Register Based
Started by ●March 29, 2013
Reply by ●April 3, 20132013-04-03
Reply by ●April 3, 20132013-04-03
"rickman" <gnuarm@gmail.com> wrote in message news:kjf48e$5qu$1@dont-email.me...> Weren't you the person who brought CISC into this discussion?Yes.> Why are you asking this question about CISC?You mentioned code density. AISI, code density is purely a CISC concept. They go together and are effectively inseparable. RISC was about effectively using all the processor clock cycles by using fast instructions. RISC wasn't concerned about the encoded size of instructions, how much memory a program consumed, the cost of memory, or how fast memory needed to be. CISC was about reducing memory consumed per instruction. CISC reduced the average size of encoded instructions while also increasing the amount of work each instruction performs. CISC was typically little-endian to reduce the space needed for integer encodings. However, increasing the amount of work per instruction produces highly specialized instructions that are the characteristic of CISC. You only need to look at the x86 instruction set to find some, e.g., STOS, LODS, XLAT, etc. They are also slow to decode and execute as compared to RISC. So, if memory is cheap and fast, there is no point in improving code density, i.e., use RISC. If memory is expensive or slow, use CISC. Arlet mentioned changes to a processor that appeared to me to have nothing to do with increasing or decreasing code density. AISI, the changes he mentioned would only affect what was in current set of MISC instructions, i.e., either a set of register-based MISC instructions or a set of stack-based MISC instructions. This was stated previously. Rod Pemberton
Reply by ●April 3, 20132013-04-03
"rickman" <gnuarm@gmail.com> wrote in message news:kjeve8$tvm$1@dont-email.me...> On 3/30/2013 5:54 PM, Rod Pemberton wrote:...> > Even if you implement CISC-like instructions, you can't > > forgo the MISC instructions you already have in order to > > add the CISC-like instructions. > > Really? I can't drop the entire instruction set and start over? > Who says so? Am I breaking a law? >It's just a logical outcome, AISI. The design criteria that you stated was that of producing MISC processors. MISC seems to be purely about the minimizing the quantity of instructions. You've produced a MISC processor. So, if you now change your mind about MISC and add additional instructions to your processor's instruction set, especially non-MISC instructions, you're effectively going against your own stated design requirement: MISC or reducing the quantity of instructions. So, it'd be you who says so, or not... It just seems contradictory with your past self to change course now with your current self.> > So, to do that, you'll need to increase > > the size of the instruction set, as well as implement > > a more complicated instruction decoder. > > Define "increase the size of the instruction set".You'll have more instructions in your instruction set.> I am using a 9 bit opcode for my stack design and am > using a similar 9 bit opcode for the register design. In what > way is the register design using a larger instruction set? >You haven't added any additional CISC-like instructions, yet. You just exchanged stack operations for register operations. So, none for now.> > I.e., that means the processor will no longer be MISC, >> but MISC+minimal CISC hybrid, or pure > > CISC... > > Nonsense. "Minimal Instruction Set Computer (MISC) is a > processor architecture with a very small number of basic > operations and corresponding opcodes." from Wikipedia. > BTW, I don't think the term MISC is widely used and is not > well defined. This is the only web page I found that even > tries to define it. > > Actually, if you consider only the opcodes and not the operand > combinations, I think the register design may have fewer > instructions than does the stack design. But the register > design still is in work so I'm not done counting yet. >How exactly does fewer instructions contribute to increased code density for the remaining instructions? The eliminated instructions are no longer a measured component of code density. I.e., they no longer consume memory and therefore aren't measured.> There are some interesting corners to be explored. For example > a MOV rx,rx is essentially a NOP. There are eight of these. So > instead, why not make them useful by clearing the register? > So MOV rx,rx is a clear to be given the name CLR rx... unless > the rx is r7 in which case it is indeed a MOV r7,r7 which is now > a NOP to be coded as such. The CLR r7 is not needed because > LIT 0 already does the same job. Even better the opcode for a > NOP is 0x1FF or octal 777. That's very easy to remember > and recognize. It feels good to find convenient features like > this and makes me like the register MISC design.I can see that you're attempting to minimize the quantity of implemented instructions. Although similar in nature, that's not the same as improving the code density. Are you conflating two different concepts? One of them reduces the encoded size of an instruction, while the other eliminates instructions ... How are you going to attempt to increase the code density for your processor? 1) adding new, additional, more powerful instructions that you don't already have 2) merging existing instruction into fewer instructions 3) finding a more compact method of instruction encoding 4) use little-endian to reduce encoded sizes of integers 5) none or other I'd think it should be #1 and #3 and #4, or #2 and #3 and #4, or "other" and #3 and #4 ... Rod Pemberton
Reply by ●April 3, 20132013-04-03
In comp.arch.fpga Rod Pemberton <do_not_have@notemailnotq.cpm> wrote:> "rickman" <gnuarm@gmail.com> wrote in message > news:kjf48e$5qu$1@dont-email.me... >> Weren't you the person who brought CISC into this discussion?> Yes.>> Why are you asking this question about CISC?> You mentioned code density. AISI, code density is purely a CISC > concept. They go together and are effectively inseparable.They do go together, but I am not so sure that they are inseperable. CISC began when much coding was done in pure assembler, and anything that made that easier was useful. (One should figure out the relative costs, but at least it was in the right direction.) That brought instructions like S/360 EDMK and VAX POLY. (Stories are that on most VAX models, POLY is slower than an explicit loop.) Now, there is no need to waste bits, and so instruction formats were defined to use the available bits. S/360 (and successors) only have three different instruction lengths, and even then sometimes waste bits. The VAX huge number of different instructions lengths, and also IA32, does seem to be for code size efficiency. VAX was also defined with a 512 byte page size, even after S/370 had 2K and 4K pages. Way too small, but maybe seemed right at the time.> RISC was about effectively using all the processor clock cycles by > using fast instructions. RISC wasn't concerned about the encoded > size of instructions, how much memory a program consumed, the > cost of memory, or how fast memory needed to be.Yes, but that doesn't mean that CISC is concerned with the size of instructions.> CISC was about reducing memory consumed per instruction. CISC > reduced the average size of encoded instructions while also > increasing the amount of work each instruction performs.Even if it is true (and it probably is) that CISC tends to make efficient use of the bits, that doesn't prove that is what CISC was about. As above, CISC was about making coding easier for programmers, specifically assembly programmers. Now, complex instructions take less space than a series of simpler instructions, but then again one could use a subroutine call. The PDP-10 has the indirect bit, allowing for nested indirection, which may or may not make efficient use of that bit. S/360 uses a sequence of L (load) instructions to do indirection. Instruction usage statistics noting how often L (load) was executed in S/360 code may have been the beginning of RISC.> CISC was typically little-endian to reduce the space needed > for integer encodings.This I don't understand at all. They take the same amount of space. Little endian does make it slightly easier to do a multiword (usually byte) add, and that may have helped for the 6502. It allows one to propagate the carry in the same order one reads bytes from memory. But once you add multiply and divide, the advantage is pretty small.> However, increasing the amount of work per instruction > produces highly specialized instructions that are the > characteristic of CISC. You only need to look at the x86 > instruction set to find some, e.g., STOS, LODS, XLAT, etc. They > are also slow to decode and execute as compared to RISC.Those are not very CISCy compared with some S/360 or VAX instructions. Now, compare to S/360 TR which will translate by looking up bytes in a lookup table for 1 to 256 byte long strings. (Unless I remember wrong, XLAT does one byte.)> So, if memory is cheap and fast, there is no point in improving > code density, i.e., use RISC. If memory is expensive or slow, use > CISC.Well, RISC is more toward using simpler instructions that compilers actually generate and executing them fast. Having one instruction size helps things go fast, and tends to be less efficient with bits. Even so, I believe that you will find that RISC designers try to make efficient use of the bits available, within the single size instruction constraint.> Arlet mentioned changes to a processor that appeared to me to have > nothing to do with increasing or decreasing code density. AISI, > the changes he mentioned would only affect what was in current set > of MISC instructions, i.e., either a set of register-based MISC > instructions or a set of stack-based MISC instructions. This was > stated previously.Decoding multiple different instruction formats tends to require complicated demultiplexers which are especially hard to do in an FPGA. Even so, one can make efficient use of the bits and still be MISC. -- glen
Reply by ●April 3, 20132013-04-03
On 4/3/2013 8:34 PM, Rod Pemberton wrote:> "rickman"<gnuarm@gmail.com> wrote in message > news:kjf48e$5qu$1@dont-email.me... > >> Weren't you the person who brought CISC into this discussion? > > Yes. > >> Why are you asking this question about CISC? > > You mentioned code density. AISI, code density is purely a CISC > concept. They go together and are effectively inseparable.Ok, so that's how you see it.> RISC was about effectively using all the processor clock cycles by > using fast instructions. RISC wasn't concerned about the encoded > size of instructions, how much memory a program consumed, the > cost of memory, or how fast memory needed to be.Don't know why you are even mentioning RISC.> CISC was about reducing memory consumed per instruction. CISC > reduced the average size of encoded instructions while also > increasing the amount of work each instruction performs. CISC was > typically little-endian to reduce the space needed for integer > encodings. However, increasing the amount of work per instruction > produces highly specialized instructions that are the > characteristic of CISC. You only need to look at the x86 > instruction set to find some, e.g., STOS, LODS, XLAT, etc. They > are also slow to decode and execute as compared to RISC.I think CISC was not solely about reducing memory used per instruction. CISC was not an area of work. CISC was not even coined until long after many CISC machines were designed. Most CISC computers were designed with very different goals in mind. For example, the x86, a CISC processor, was initially designed to extend the x86 instruction set to a 16 bit processor and then to a 32 bit processor. The goal was just to develop an instruction set that was backwards compatible with existing processors while adding capabilities that would make 32 bit processors marketable.> So, if memory is cheap and fast, there is no point in improving > code density, i.e., use RISC. If memory is expensive or slow, use > CISC.LOL, that is a pretty MINIMAL analysis of computers, so I guess it is MACA, Minimal Analysis of Computer Architectures.> Arlet mentioned changes to a processor that appeared to me to have > nothing to do with increasing or decreasing code density. AISI, > the changes he mentioned would only affect what was in current set > of MISC instructions, i.e., either a set of register-based MISC > instructions or a set of stack-based MISC instructions. This was > stated previously.This is so far out of context I can't comment. -- Rick
Reply by ●April 4, 20132013-04-04
On 4/3/2013 8:35 PM, Rod Pemberton wrote:> "rickman"<gnuarm@gmail.com> wrote in message > news:kjeve8$tvm$1@dont-email.me... >> On 3/30/2013 5:54 PM, Rod Pemberton wrote: > ... > >>> Even if you implement CISC-like instructions, you can't >>> forgo the MISC instructions you already have in order to >>> add the CISC-like instructions. >> >> Really? I can't drop the entire instruction set and start over? >> Who says so? Am I breaking a law? >> > > It's just a logical outcome, AISI. The design criteria that you > stated was that of producing MISC processors. MISC seems to be > purely about the minimizing the quantity of instructions. You've > produced a MISC processor. So, if you now change your mind about > MISC and add additional instructions to your processor's > instruction set, especially non-MISC instructions, you're > effectively going against your own stated design requirement: MISC > or reducing the quantity of instructions. So, it'd be you who > says so, or not... It just seems contradictory with your past > self to change course now with your current self.Your logic seems to be flawed on so many levels. I don't think I stated that producing a MISC processor was a "design criteria". It doesn't even make sense to have that as a "design criteria". I never said I was "adding" instructions to some existing instruction set. In fact, I think I've said that the instruction set for the register based MISC processor is so far, *smaller* than the instruction set for the stack based MISC processor as long as you don't consider each combination of X and Y in MOV rx,ry to be a separate instruction. If you feel each combination is a separate instruction then they both have approximately the same number of instructions since they both have 9 bit instructions and so have 512 possible instructions.>>> So, to do that, you'll need to increase >>> the size of the instruction set, as well as implement >>> a more complicated instruction decoder. >> >> Define "increase the size of the instruction set". > > You'll have more instructions in your instruction set.Sorry, that isn't a good definition because you used part of the term you are defining in the definition.>> I am using a 9 bit opcode for my stack design and am >> using a similar 9 bit opcode for the register design. In what >> way is the register design using a larger instruction set? >> > > You haven't added any additional CISC-like instructions, yet. You > just exchanged stack operations for register operations. So, > none for now.Ok, now we are getting somewhere. In fact, if you read my other posts, you will find that I *won't* be adding any CISC instructions because one of my stated "design criteria" is that each instruction executes in one clock cycle. It's pretty hard to design a simple machine that can do "complex" instructions without executing them in multiple clock cycles.>>> I.e., that means the processor will no longer be MISC, >>> but MISC+minimal CISC hybrid, or pure >>> CISC... >> >> Nonsense. "Minimal Instruction Set Computer (MISC) is a >> processor architecture with a very small number of basic >> operations and corresponding opcodes." from Wikipedia. >> BTW, I don't think the term MISC is widely used and is not >> well defined. This is the only web page I found that even >> tries to define it. >> >> Actually, if you consider only the opcodes and not the operand >> combinations, I think the register design may have fewer >> instructions than does the stack design. But the register >> design still is in work so I'm not done counting yet. >> > > How exactly does fewer instructions contribute to increased code > density for the remaining instructions? The eliminated > instructions are no longer a measured component of code density. > I.e., they no longer consume memory and therefore aren't measured.Not sure what you mean here. Code density how many instructions it takes to do a given amount of work. I measure this by writing code and counting the instructions it takes. Right now I have a section of code I am working on that performs the DDS calculations from a set of control inputs to the DDS. This is what I was working on when I realized that a register based design likely could do this without the stack ops, OVER mainly, but also nearly all the others that just work on the top two stack items. So far it appears the register based instructions are significantly more compact than the stack based instructions. Just as important, the implementation appears to be simpler for the register based design. But that is just *so far*. I am still working on this. The devil is in the details and I may find some aspects of what I am doing that cause problems and can't be done in the instruction formats I am planning or something blows up the hardware to be much bigger than I am picturing at the moment.>> There are some interesting corners to be explored. For example >> a MOV rx,rx is essentially a NOP. There are eight of these. So >> instead, why not make them useful by clearing the register? >> So MOV rx,rx is a clear to be given the name CLR rx... unless >> the rx is r7 in which case it is indeed a MOV r7,r7 which is now >> a NOP to be coded as such. The CLR r7 is not needed because >> LIT 0 already does the same job. Even better the opcode for a >> NOP is 0x1FF or octal 777. That's very easy to remember >> and recognize. It feels good to find convenient features like >> this and makes me like the register MISC design. > > I can see that you're attempting to minimize the quantity of > implemented instructions. Although similar in nature, that's not > the same as improving the code density. Are you conflating two > different concepts? One of them reduces the encoded size of an > instruction, while the other eliminates instructions ...You really don't seem to understand what I am doing. You continually misinterpret what I explain.> How are you going to attempt to increase the code density for your > processor? > > 1) adding new, additional, more powerful instructions that you > don't already have > 2) merging existing instruction into fewer instructions > 3) finding a more compact method of instruction encoding > 4) use little-endian to reduce encoded sizes of integers > 5) none or other > > I'd think it should be #1 and #3 and #4, or #2 and #3 and #4, or > "other" and #3 and #4 ...Uh, I am designing an instruction set that does as much as possible with as little hardware as possible. When you say, "new, additional" instructions, compared to what? When you say "more compact", again, compared to what exactly? When you say "litte-endian" to reduce encoded integer size, what exactly is that? Are you referring to specifying an integer in small chunks so that sign extension allows the specification to be limited in length? Yes, that is done on both the stack and register based designs. Koopmans paper lists literals and calls as some of the most frequently used instructions, so optimizing literals optimizes the most frequently used instructions. -- Rick
Reply by ●April 4, 20132013-04-04
On 29/03/2013 21:00, rickman wrote:> I have been working with stack based MISC designs in FPGAs for some > years. All along I have been comparing my work to the work of others. > These others were the conventional RISC type processors supplied by the > FPGA vendors as well as the many processor designs done by individuals > or groups as open source.<snip> Can you achieve as fast interrupt response times on a register-based machine as a stack machine? OK, shadow registers buy you one fast interrupt, but that's sort of a one-level 2D stack. Even the venerable RTX2000 had an impressive (IIRC) 200ns interrupt response time. Cheers -- Syd
Reply by ●April 4, 20132013-04-04
On 04/04/2013 10:38 AM, Syd Rumpo wrote:> On 29/03/2013 21:00, rickman wrote: >> I have been working with stack based MISC designs in FPGAs for some >> years. All along I have been comparing my work to the work of others. >> These others were the conventional RISC type processors supplied by the >> FPGA vendors as well as the many processor designs done by individuals >> or groups as open source. > > <snip> > > Can you achieve as fast interrupt response times on a register-based > machine as a stack machine? OK, shadow registers buy you one fast > interrupt, but that's sort of a one-level 2D stack. > > Even the venerable RTX2000 had an impressive (IIRC) 200ns interrupt > response time.It depends on the implementation. The easiest thing would be to not save anything at all before jumping to the interrupt handler. This would make the interrupt response really fast, but you'd have to save the registers manually before using them. It would benefit systems that don't need many (or any) registers in the interrupt handler. And even saving 4 registers at 100 MHz only takes an additional 40 ns. If you have parallel access to the stack/program memory, you could like the Cortex, and save a few (e.g. 4) registers on the stack, while you fetch the interrupt vector, and refill the execution pipeline at the same time. This adds a considerable bit of complexity, though. If you keep the register file in a large memory, like a internal block RAM, you can easily implement multiple sets of shadow registers. Of course, an FPGA comes with flexible hardware such as large FIFOs, so you can generally avoid the need for super fast interrupt response. In fact, you may not even need interrupts at all.
Reply by ●April 4, 20132013-04-04
In article <kjin8q$so5$1@speranza.aioe.org>, glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:>In comp.arch.fpga Rod Pemberton <do_not_have@notemailnotq.cpm> wrote: >> "rickman" <gnuarm@gmail.com> wrote in message >> news:kjf48e$5qu$1@dont-email.me... >>> Weren't you the person who brought CISC into this discussion? > >> Yes. > >>> Why are you asking this question about CISC? > >> You mentioned code density. AISI, code density is purely a CISC >> concept. They go together and are effectively inseparable. > >They do go together, but I am not so sure that they are inseperable. > >CISC began when much coding was done in pure assembler, and anything >that made that easier was useful. (One should figure out the relative >costs, but at least it was in the right direction.)But, of course, this is a fallacy. The same goal is accomplished by macro's, and better. Code densitity is the only valid reason. <SNIP>> >Decoding multiple different instruction formats tends to require >complicated demultiplexers which are especially hard to do in >an FPGA. Even so, one can make efficient use of the bits >and still be MISC.> >-- glen-- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Reply by ●April 4, 20132013-04-04
On 04/04/2013 01:16 PM, Albert van der Horst wrote:>>> You mentioned code density. AISI, code density is purely a CISC >>> concept. They go together and are effectively inseparable. >> >> They do go together, but I am not so sure that they are inseperable. >> >> CISC began when much coding was done in pure assembler, and anything >> that made that easier was useful. (One should figure out the relative >> costs, but at least it was in the right direction.) > > But, of course, this is a fallacy. The same goal is accomplished by > macro's, and better. Code densitity is the only valid reason.Speed is another valid reason.
