By: Björn Ragnar Björnsson (bjorn.ragnar.delete@this.gmail.com), August 7, 2022 5:14 pm
Room: Moderated Discussions
Marcus (m.delete@this.bitsnbites.eu) on August 7, 2022 10:16 am wrote:
> Adrian (a.delete@this.acm.org) on August 3, 2022 2:00 am wrote:
> > Anon (no.delete@this.spam.com) on August 2, 2022 11:46 am wrote:
> > >
> > > Getting quality data is much harder than you think, unlike you I have seen a lot of empirical
> > > data, often contradictory data, the problem is that the data depends on compiler technology,
> > > the existing ISAs, the workload, etc, improve one side and the other becomes suboptimal.
> > >
> >
> > [snip]
> >
> > After compiling the static frequencies from the entire set of programs can be gathered trivially for any
> > instruction feature, e.g. to count the instructions with the same mnemonic and sort them by frequency:
> >
> > objdump -d /usr/bin/* | cut -f3 | grep -oE "^[a-z]+" | sort | uniq -c | sort -n
> >
> >
> > This is just the simplest example. Classifying the immediate constants by
> > size ranges would require more sophisticated parsing of the disassembly output,
> > but that would still not be difficult for a Python/Perl/AWK script.
> >
>
> I have found that you can cover more useful/common immediate value ranges by using "clever" (non-linear) encodings.
> E.g. in MRISC32 (a 32-bit RISC ISA with fixed instruction word size) I have a 15-bit immediate field for regular
> arithmetic and logical operations etc. I decided to use one of the 15 bits to signify HI (1) or LO (0), and
> position the rest of the 14 bits accordingly in the actual 32-bit value (constant operand). Thus the following
> constants are possible to express with the 15-bit field of the instruction word:
>
> MUL R7,R1,#-42 // LO (sign extend)
> AND R8,R2,#0x7F800000 // HI
> XOR R9,R3,#0x000FFFFF // HI (bit-extend LSB into lower part)
>
> And there's a similar encoding trick for loading larger immediate values (1+20 bits immediate
> field), that can be used for loading many binary32 FP constants too, for instance.
>
> My point is that just gathering statistics on immediate value ranges (e.g. a histogram
> of log2(abs(x))) may not be optimal when designing an ISA. You really need to look into
> different use cases (aritmetic, bitwise, memory offsets, floating-point, etc) and take
> into account possible encoding variants for different instruction classes.
>
> /Marcus
>
I hadn't seen MRISC32 before. At first glance it looks pretty good, a very respectable start. Congrats on that Marcus. Probably good enough for embedded and IOT stuff. Lot's left to do to make it usable in a modern general purpose computer. You probably don't need my advice but I'll give it anyway. When completing the spec in the general purpose direction take special note of Linus' numerous and detailed notes on memory ordering here at realworldtech.
> Adrian (a.delete@this.acm.org) on August 3, 2022 2:00 am wrote:
> > Anon (no.delete@this.spam.com) on August 2, 2022 11:46 am wrote:
> > >
> > > Getting quality data is much harder than you think, unlike you I have seen a lot of empirical
> > > data, often contradictory data, the problem is that the data depends on compiler technology,
> > > the existing ISAs, the workload, etc, improve one side and the other becomes suboptimal.
> > >
> >
> > [snip]
> >
> > After compiling the static frequencies from the entire set of programs can be gathered trivially for any
> > instruction feature, e.g. to count the instructions with the same mnemonic and sort them by frequency:
> >
> > objdump -d /usr/bin/* | cut -f3 | grep -oE "^[a-z]+" | sort | uniq -c | sort -n
> >
> >
> > This is just the simplest example. Classifying the immediate constants by
> > size ranges would require more sophisticated parsing of the disassembly output,
> > but that would still not be difficult for a Python/Perl/AWK script.
> >
>
> I have found that you can cover more useful/common immediate value ranges by using "clever" (non-linear) encodings.
> E.g. in MRISC32 (a 32-bit RISC ISA with fixed instruction word size) I have a 15-bit immediate field for regular
> arithmetic and logical operations etc. I decided to use one of the 15 bits to signify HI (1) or LO (0), and
> position the rest of the 14 bits accordingly in the actual 32-bit value (constant operand). Thus the following
> constants are possible to express with the 15-bit field of the instruction word:
>
> MUL R7,R1,#-42 // LO (sign extend)
> AND R8,R2,#0x7F800000 // HI
> XOR R9,R3,#0x000FFFFF // HI (bit-extend LSB into lower part)
>
> And there's a similar encoding trick for loading larger immediate values (1+20 bits immediate
> field), that can be used for loading many binary32 FP constants too, for instance.
>
> My point is that just gathering statistics on immediate value ranges (e.g. a histogram
> of log2(abs(x))) may not be optimal when designing an ISA. You really need to look into
> different use cases (aritmetic, bitwise, memory offsets, floating-point, etc) and take
> into account possible encoding variants for different instruction classes.
>
> /Marcus
>
I hadn't seen MRISC32 before. At first glance it looks pretty good, a very respectable start. Congrats on that Marcus. Probably good enough for embedded and IOT stuff. Lot's left to do to make it usable in a modern general purpose computer. You probably don't need my advice but I'll give it anyway. When completing the spec in the general purpose direction take special note of Linus' numerous and detailed notes on memory ordering here at realworldtech.