riscv code density

[Vince Weaver]

Hello

I have a project where I explore code-density by porting the same small
program to a lot of different assembly languages.

http://www.deater.net/weave/vmwprod/asm/ll/

I just added support for both riscv and riscv compressed.

Feel free to take a look, and if I missed any obvious implementation
tricks let me know.

The code is missing some optimizations, mostly because it was hard to get
the assembler to do certain things.


Vince Weaver
vincent...@maine.edu

[Bruce Hoult]

Oh cool, I'd been meaning to base a RISC-V version off the MIPS one for a while, and submit it. Glad you got to it first.

Vince Weaver
vincent...@maine.edu

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/alpine.DEB.2.20.1705251351530.26459%40macbook-air.

[Bruce Hoult]

c.jal won't work because it doesn't exist in 64 bit mode, making way for addiw.

On Thu, May 25, 2017 at 8:52 PM, Vince Weaver <vincent...@maine.edu> wrote:

Vince Weaver
vincent...@maine.edu

[Vince Weaver]

On Fri, 26 May 2017, Bruce Hoult wrote:

> Oh cool, I'd been meaning to base a RISC-V version off the MIPS one for
> a while, and submit it. Glad you got to it first.

Some Amiga/m68k diehards were upset about their ranking on the list and
bugged me until I got the project restarted again.

> c.jal won't work because it doesn't exist in 64 bit mode, making way for
> addiw.

Ah, good to know. I was hoping to avoid having a separate 32-bit version.
I somehow thought things were like mips where 64/32 was mostly identical
except for register size.

I wish the assembler gave better errors, but I guess "gas" is mostly
designed to be used by the compiler anyway.

I was also going to complain about not having a short "lbu" instruction.
Though last night I realized that on a little-endian system you can still
use "lw" in that case as long as you don't care about the upper bits.
This shaved another 4 bytes off of the LZSS results.

Vince

[David Kipping]

In the graphic, it may avoid confusion to show that the risc-v values are for 64 bit.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.

To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/alpine.DEB.2.20.1705261029520.29561%40macbook-air.

[Palmer Dabbelt]

On Fri, 26 May 2017 08:27:16 PDT (-0700), dkip...@qti.qualcomm.com wrote:
> In the graphic, it may avoid confusion to show that the risc-v values are for 64 bit.
>
> -----Original Message-----
> From: Vince Weaver [mailto:vincent...@maine.edu]
> Sent: Friday, May 26, 2017 7:35 AM
> To: Bruce Hoult <br...@hoult.org>
> Cc: RISC-V SW Dev <sw-...@groups.riscv.org>
> Subject: Re: [sw-dev] riscv code density
>
> On Fri, 26 May 2017, Bruce Hoult wrote:
>
>> Oh cool, I'd been meaning to base a RISC-V version off the MIPS one
>> for a while, and submit it. Glad you got to it first.
>
> Some Amiga/m68k diehards were upset about their ranking on the list and bugged me until I got the project restarted again.
>
>> c.jal won't work because it doesn't exist in 64 bit mode, making way
>> for addiw.
>
> Ah, good to know. I was hoping to avoid having a separate 32-bit version.
> I somehow thought things were like mips where 64/32 was mostly identical except for register size.
>
> I wish the assembler gave better errors, but I guess "gas" is mostly designed to be used by the compiler anyway.

If there's anything specific then feel free to open a bug on our GitHub page

https://github.com/riscv/riscv-binutils-gdb/issues

and I'll try to see what I can do. You're also welcome to submit a patch or
pull request as well.

Thanks for porting your stuff to RISC-V!

[Vince Weaver]

On Fri, 26 May 2017, David Kipping wrote:

> In the graphic, it may avoid confusion to show that the risc-v values
> are for 64 bit.

yes, though at some point the graph gets unreadable with the long string
of alphanums following the riscv name.

It's beginning to look like if I want to be complete I really should have
results for all of the following? Maybe I can get away with some ifdefs
rather than having to completely recode by hand for all of them.

RV32I
RV32IC
RV32IM
RV32ICM
RV32IE
RV32ICEM
RV64I
RV64IC
RV64IM
RV64ICM
RV128I
RV128IC
RV128IM
RV128ICM

[Bruce Hoult]

That's getting a bit extreme :-)

There will be essentially no difference (zero difference in size I think?) between 32, 64 or 128 bit if you don't use the C extension.

In the C extension, 64 bit and 128 bit differ only in float load/store double FP disappearing in favour of load/store int128. So no difference for your code.

So 128 bit versions are not worth doing at all.

Similarly, the differences in C between 32 bit and 64 bit are only load/store single FP disappearing in favour of load/store int64, and c.jal disappearing in favour of c.addiw (which personally makes me unhappy).

I'd forget E. That's likely to be used in situations where there is barely any code at all and they simply don't care about code size. If they don't want to spend the die size for 16 registers they probably aren't going to have multiply or a compressed instruction decoder either (although it is permitted). And no OS :-) N.B. "E" replaces "I", so it's RV32E, not RV32IE.

M is more annoying. You could code up divmod by 10 for the printing of integers. That will make a quite significant code size difference for such a small program. Do you even count that for other platforms without a divide instruction? Maybe it makes more sense to count the size of a function call to a divmod runtime library function, but just assume that function exists, rather than counting its size?

I think I'd stick to no more than:

RV32IM

RV32IMC

RV64IMC

Maybe RV32E if you really must :-)

[Vince Weaver]

On Fri, 26 May 2017, Bruce Hoult wrote:

> That's getting a bit extreme :-)
>
> There will be essentially no difference (zero difference in size I think?)
> between 32, 64 or 128 bit if you don't use the C extension.

I wouldn't think so, but the overall executable size definitely changes
(though that could be to elf header differences).

I have things working on 32-bit builds now, I'll update the graphs later
today.

> So 128 bit versions are not worth doing at all.

Would still be interested in doing if possible, as I don't have any 128
bit architectures.

> I'd forget E. That's likely to be used in situations where there is barely
> any code at all and they simply don't care about code size. If they don't
> want to spend the die size for 16 registers they probably aren't going to
> have multiply or a compressed instruction decoder either (although it is
> permitted). And no OS :-) N.B. "E" replaces "I", so it's RV32E, not RV32IE.

The ll_asm code definitely follows different patters depending on whether
32, 16, 8, or 3 registers are available so it might be worth checking
anyway.

> M is more annoying. You could code up divmod by 10 for the printing of
> integers. That will make a quite significant code size difference for such a
> small program. Do you even count that for other platforms without a divide
> instruction? Maybe it makes more sense to count the size of a function call
> to a divmod runtime library function, but just assume that function exists,
> rather than counting its size?

It gets complicated accounting for it, especially as some architectures
have no divide, and some have partial divide.

I have to admit I don't really sort out the divide/no-divide stuff on ARM
very well, but if you did want to do a fair comparison between ARM/Thumb2
you should take into account the availability of divide.

Vince

[Tommy Murphy]

You really need to look at the output of size (e.g. riscv64-unknown-elf-size) and not the size of the ELF file itself.

[Vince Weaver]

On Fri, 26 May 2017, Tommy Murphy wrote:

> You really need to look at the output of size (e.g.
> riscv64-unknown-elf-size) and not the size of the ELF file itself.

I look at the disassembled code and measure things directly.

I still also report the overall binary size. While it's not strictly
code density, it's still important as most people aren't executing raw
instruction streams. It doesn't matter how dense your code is if your OS
won't let you run it without a lot of overhead. Architectural
ABI decisions can affect executable density, for example the recent change
to recquire an ABIFLAGS ELF section on MIPS.

Vince

[Tommy Murphy]

On Friday, 26 May 2017 23:29:00 UTC+1, Vince Weaver wrote:

On Fri, 26 May 2017, Tommy Murphy wrote:

> You really need to look at the output of size (e.g.
> riscv64-unknown-elf-size) and not the size of the ELF file itself.

I look at the disassembled code and measure things directly.

Fair enough.

 

I still also report the overall binary size.  

But the ELF size is not the ("ROMable") binary size.

[Vince Weaver]

On Fri, 26 May 2017, Bruce Hoult wrote:

> I think I'd stick to no more than:
>
> RV32IM
> RV32IMC
> RV64IMC
>
> Maybe RV32E if you really must :-)

In the end I am now tracking RV32IM/RV32IMC/RV64IM/RV64IMC

I don't think the toolchain currently supports RV32E/RV128I from what I
can tell? So that left those out.

And I decided not to try RV-without-M for now, but yes for example my
THUMB/THUMB2 code does count the needed div emulation code in the routines
that use a divide. I probably should have separate armv5/6/7/8 code but
that will be painful.

Anyway the website graphs should be current, and have better naming now.

I also have updated mips/micromips/thumb/thumb2 results, randomly came
across a forum posting from 2012 where someone posted a clever hack to
shave some bytes off of lzss if your compressed ISA has a short
"negate register" instruction, which unfortunately I don't think riscv-c
has.

Vince