Heater
Posts: 16846
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Sat Aug 08, 2020 12:16 pm

jahboater wrote:
Sat Aug 08, 2020 8:18 am
For your amusement, there is another way - function attributes.
Until such time as function attributes become standardized in C they are not really up for language comparisons.

But jeez, what a heinous mess of a syntactic aberration function attributes are. Eeeww.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 6290
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Sat Aug 08, 2020 12:49 pm

Heater wrote:
Sat Aug 08, 2020 12:16 pm
But jeez, what a heinous mess of a syntactic aberration function attributes are. Eeeww.
Yes indeed. I see its called "uglification" :)

You are obviously not expected to use them as-is (at least not until the C++ syntax is standardized in C I guess).
Pi4 8GB running PIOS64 Lite

User avatar
clicky
Posts: 501
Joined: Thu Oct 25, 2012 7:34 am

Re: Anyone using Rust on a PI ?

Sat Aug 08, 2020 1:17 pm

Didn't PIC µController have some strange bit size data in ROM (eeprom?). Or maybe in memory, too? I don't think it's same as with Atmel's stuff where it is just trimmed down 16bit or something like that... Maybe I just imagined it - it was a decade or more ago ¯\_(ツ)_/¯

And on that tangent - Rust on µControllers seems like a good balance between low level (direct metal stuff C almost provides) and much higher programming. And while on that tangent - Rust definitively seems like good trade off for bare metal Pi. Did we mention https://github.com/rust-embedded/rust-r ... -tutorials ?

ejolson
Posts: 6016
Joined: Tue Mar 18, 2014 11:47 am

Re: Anyone using Rust on a PI ?

Sat Aug 08, 2020 1:48 pm

jahboater wrote:
Sat Aug 08, 2020 12:49 pm
Heater wrote:
Sat Aug 08, 2020 12:16 pm
But jeez, what a heinous mess of a syntactic aberration function attributes are. Eeeww.
Yes indeed. I see its called "uglification" :)

You are obviously not expected to use them as-is (at least not until the C++ syntax is standardized in C I guess).
It seems almost everything is starting to rust. Here is what happens to C after it has been left out in the rain

https://www.microsoft.com/en-us/researc ... checked-c/

I know some factories are rusting too. Is it all caused by the coronavirus?

Heater
Posts: 16846
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Sat Aug 08, 2020 3:06 pm

Oh my. I hope they don't leave C out in the rain too long. This is what checked C looks like already:

Code: Select all

void append(
    _Array_ptr<char> dst : count(dst_count),
    _Array_ptr<char> src : count(src_count),
    size_t dst_count, size_t src_count)
{
    _Dynamic_check(src_count <= dst_count);
    for (size_t i = 0; i < src_count; i++) {
        if (src[i] == ’\0’) {
            break;
        }
        dst[i] = src[i];
    }
}

size_t my_strlcpy(
    _Nt_array_ptr<char> dst: count(dst_sz - 1),
    _Nt_array_ptr<char> src, size_t dst_sz)
{
    size_t i = 0;
    _Nt_array_ptr<char> s : count(i) = src;
    while (s[i] != ’\0’ && i < dst_sz - 1) {
        dst[i] = s[i];
        ++i;  
    }
    dst[i] = ’\0’;
    return i;
}
From : https://www.microsoft.com/en-us/researc ... eprint.pdf
Memory in C++ is a leaky abstraction .

hippy
Posts: 8555
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Anyone using Rust on a PI ?

Sat Aug 08, 2020 7:23 pm

clicky wrote:
Sat Aug 08, 2020 1:17 pm
Didn't PIC µController have some strange bit size data in ROM (eeprom?).
Yes; some PICmicros have 12-bit and 14-bit wide instruction sets with the same width ROM / PROM / Flash. But that's fairly normal for Harvard Architectures with separate code and data. Registers and Data Eeprom are 8-bit.

It does make for some trickiness when self programming, for boot-loaders mainly, but it's not too bad.

Heater
Posts: 16846
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 12:15 am

Yeah, the classic PIC micros are a bit weird.

Which probably explains why there is no GCC target for those PICs whilst there is one, avr-gcc, for the similarly small ATMEL AVRs. As used by Arduino.

I gather that there are C compilers for those little PICs though. I wonder if they are feature complete standard C or not.
Memory in C++ is a leaky abstraction .

hippy
Posts: 8555
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 11:51 am

Heater wrote:
Sun Aug 09, 2020 12:15 am
I gather that there are C compilers for those little PICs though. I wonder if they are feature complete standard C or not.
I have no idea, but then I'm not sure what the definition of "feature complete standard C" is.

MPLAB XC compilers are Microchip's official (free) offering but there are many alternatives. I personally favour B Knudsen Data compilers - http://www.bknd.com

I don't believe most programming on the smaller PICmicro devices really care what 'standards' the compilers comply with, only that they support enough C to get the job done. Efficient and predictable code generation is more important when one has as little as 512-words of code space and 25 bytes of RAM.

I have said in the past that people using C compilers for PICmicro are often using C as nothing more than a macro assembler, but that view has been rejected in this forum.

Heater
Posts: 16846
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 12:07 pm

hippy wrote:
Sun Aug 09, 2020 11:51 am
I'm not sure what the definition of "feature complete standard C"
Clear enough is it not? Conforming to some version of the C standard as published in the appropriate ISO standard document.

Of course we don't expect support for all or even any of the standard library functions, space will likely not allow it.

I have no idea how complete PIC C compilers are, just wondering.
hippy wrote:
Sun Aug 09, 2020 11:51 am
I have said in the past that people using C compilers for PICmicro are often using C as nothing more than a macro assembler, but that view has been rejected in this forum.
I don't recall that particular version of the view has been rejected. If those PIC C compilers are not actually standard C I would begin to agree with you. And most likely code written for the PIC is never expected to be compiled with anything else or used on any other platform. So that does start to look like a 'macro assembler'.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 6290
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 3:35 pm

Heater wrote:
Sun Aug 09, 2020 12:07 pm
hippy wrote:
Sun Aug 09, 2020 11:51 am
I'm not sure what the definition of "feature complete standard C"
Clear enough is it not? Conforming to some version of the C standard as published in the appropriate ISO standard document.
Given the glacially slow rate of increase in capability between each successive C version (every 10 years roughly), I expect full conformance to the latest published ISO standard as the minimum. GCC and other advanced compilers usually have support for future (draft) standards (C2x at the time of writing).
Heater wrote:
Sun Aug 09, 2020 12:07 pm
Of course we don't expect support for all or even any of the standard library functions, space will likely not allow it.
I do expect such support if its mandated in the standard.

Of course its a different matter for compilers targeting a machine with only 25 bytes of RAM ...
Pi4 8GB running PIOS64 Lite

Heater
Posts: 16846
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 5:22 pm

jahboater wrote:
Sun Aug 09, 2020 3:35 pm
I do expect such support if its mandated in the standard.

Of course its a different matter for compilers targeting a machine with only 25 bytes of RAM ...
Exactly. So we agree.

The C language syntax and semantics may well be able to generate code that can live in a handful of bytes or RAM.

But I'm pretty sure we cannot expect to be using standard library functions like printf in that space. Floating point support is almost certainly impossible.

I was amazed when they got GCC generating code for the Parallax Inc. Propeller micro-controller that did actually support some limited printf in the 32K bytes of RAM the Propeller has. Even more amazed when said GCC could also parallelize code over the 8 cores in the Propeller with OpenMP.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 6290
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 5:27 pm

Heater wrote:
Sat Aug 08, 2020 3:06 pm
This is what checked C looks like already:
Horrid!
I speculate that more bugs are introduced by unreadable/unmaintainable code than are ever a problem with bounds errors.
Pi4 8GB running PIOS64 Lite

User avatar
clicky
Posts: 501
Joined: Thu Oct 25, 2012 7:34 am

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 5:29 pm

Heater wrote:
Sun Aug 09, 2020 5:22 pm
Exactly. So we agree.

The C language syntax and semantics may well be able to generate code that can live in a handful of bytes or RAM.

But I'm pretty sure we cannot expect to be using standard library functions like printf in that space. Floating point support is almost certainly impossible.

I was amazed when they got GCC generating code for the Parallax Inc. Propeller micro-controller that did actually support some limited printf in the 32K bytes of RAM the Propeller has. Even more amazed when said GCC could also parallelize code over the 8 cores in the Propeller with OpenMP.
Same here with avr-gcc - I was comparing result with what I would have done in assembler and it wasn't far off. Maybe 10-20% worse in general, but without any hassle...

I am now very curious how good is rust in such tight ram/eeprom environment...

User avatar
jahboater
Posts: 6290
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 5:31 pm

Heater wrote:
Sun Aug 09, 2020 5:22 pm
But I'm pretty sure we cannot expect to be using standard library functions like printf in that space.
Yes indeed.
Its up to the user not to call printf if they are trying to save memory - that's the been the case since the dawn of time!
Pi4 8GB running PIOS64 Lite

ejolson
Posts: 6016
Joined: Tue Mar 18, 2014 11:47 am

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 5:57 pm

jahboater wrote:
Sun Aug 09, 2020 5:31 pm
Heater wrote:
Sun Aug 09, 2020 5:22 pm
But I'm pretty sure we cannot expect to be using standard library functions like printf in that space.
Yes indeed.
Its up to the user not to call printf if they are trying to save memory - that's always the been the case since the dawn of time!
On a desktop replacement, such as the Raspberry Pi in which 50 other running tasks have already paged in the glibc shared library, the footprint of printf is only the size of the page table needed to link to the routines already in memory.

Shared libraries help make practical the ideal of having different tools that each perform a single task well: Individual binaries are smaller and load faster because the shared libraries are already resident in memory.

When things get rusty the alternative is to download crate upon crate upon crate of independently maintained source code that is statically included in every binary.

User avatar
jahboater
Posts: 6290
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 6:14 pm

ejolson wrote:
Sun Aug 09, 2020 5:57 pm
On a desktop replacement, such as the Raspberry Pi in which 50 other running tasks have already paged in the glibc shared library, the footprint of printf is only the size of the page table needed to link to the routines already in memory.

Shared libraries help make practical the ideal of having different tools that each perform a single task well: Individual binaries are smaller and load faster because the shared libraries are already resident in memory.
Exactly.
Also the fixed parts of a program or library (the executable "text" segment and the read-only data) need not be swapped out when memory gets low - it is simply read back in from the original program file when the program runs again.
ejolson wrote:
Sun Aug 09, 2020 5:57 pm
When things get rusty the alternative is to download crate upon crate upon crate of independently maintained source code that is statically included in every binary.
That doesn't sound good for a "systems programming" language.
Pi4 8GB running PIOS64 Lite

Heater
Posts: 16846
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 6:19 pm

clicky wrote:
Sun Aug 09, 2020 5:29 pm
I am now very curious how good is rust in such tight ram/eeprom environment...
Good question.

In principle languages like Pascal, PLM, Ada, C, C++, Rust etc compile the logic in your source code down to the minimum required instructions. If they don't that is down to differences in their compiler technology and the optimizations it applies.

Also the only use as much RAM as is required for the variables you define in your program.

They require no "run-times" to support them. They just produce executable instructions.

As such I see no reason why Rust would be at any disadvantage in small spaces over any similar compiled language.

Is this actually true?

Well, the closest I can come is that you can write code for 8 bit ATMEL AVR processors, like the Arduino, in Rust: https://github.com/avr-rust. Perhaps not perfected yet.

Or the project by Cliff Biffle to generate VGA graphics from an STM32 micro-controller in C and Rust: http://cliffle.com/blog/m4vga-in-rust/

His conclusion:
The Rust implementation is simpler, shorter (in lines of code), faster, and smaller (in bytes of Flash) than my heavily-optimized C++ version — and because it's almost entirely safe code, several types of bugs that I fought regularly, such as race conditions and dangling pointers, are now caught by the compiler.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 6290
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 6:29 pm

Heater wrote:
Sun Aug 09, 2020 6:19 pm
They require no "run-times" to support them. They just produce executable instructions.
I guess you mean:

Code: Select all

-ffreestanding
    Assert that compilation targets a freestanding environment.  This implies
    -fno-builtin.  A freestanding environment is one in which the standard library may not
    exist, and program startup may not necessarily be at "main".  The most obvious example
    is an OS kernel.  This is equivalent to -fno-hosted.
which I presume Rust has an equivalent.

I'm not sure how many languages apart from assembler have such an option (assembler doesn't need it of course).

It might be an interesting "challenge" to produce the smallest hosted program for the Pi in different languages!
Pi4 8GB running PIOS64 Lite

Heater
Posts: 16846
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 6:55 pm

jahboater wrote:
Sun Aug 09, 2020 6:14 pm
That doesn't sound good for a "systems programming" language.
Hmm...

My idea of a "systems programming" programming language is a language that you can use on bare-metal devices, to build operating systems from scratch, and so on. In such 'systems programming' you have no libraries to depend on, static, dynamic or otherwise. See Linux kernel for example.

Rust can certainly do all of that because the code it generates does not depend on any external libraries or require a run time engine to support it. Consequently we see Rust being used to build operating systems like Redox. Used for Linux kernel modules. And used to program bare metal micro-controllers.

So what about those hundreds of Rust libraries (crates) that ejolson talks about, that are pulled in when people start building programs on Linux or Windows or whatever and are all compiled with your project and statically linked ?

That can certainly be annoying at first sight. But consider:

If your aim is to use Rust so that it can prove the memory safety of your program as much as possible then every bit of functionality you are too lazy to write for yourself had better be pulled in as source and check by the compiler. As much as possible.

To keep life predictable and sane it is probably a good idea to know exactly what versions of such libraries (crates) you are using. Then you can at least rebuild your program repeatably. Which pretty much rules out depending on whatever junk comes with your operating system's packages.

That is of course an issue in the C/C++ world where applications are often delivered with their own versions of libraries that they use, even if the OS has some other versions installed.

In fact, that is the entire motivation behind Docker images and Snap packages etc. to deliver ones applications. Bundle the whole damn thing and all it's dependencies in one huge blob.

Typically I find all that crate downloading and compiling is not a problem. Yes it takes what seems like a long time when building a new program from scratch. But that does not happen very often. When riffing on code a 'cargo build' that only compiles things you have changed, is as quick as any C++ build and often one only uses 'cargo check' to do a quick syntax check as one proceeds.
Memory in C++ is a leaky abstraction .

Heater
Posts: 16846
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 7:32 pm

There was a post I was replying to that got deleted.
jahboater wrote:
Sun Aug 09, 2020 7:06 pm
You have to trust the main system libraries do you not ?
Do you?

In the extreme one could write programs to run on Linux that don't use any libraries, statically, dynamically or otherwise. All you need to do is be an executable format that Linux will load and run, you can do all your I/O via Linux syscalls.

As it happens typical Rust programs still rely on libc and and friends to provide the low level interface to the OS. But I don't see that as necessary, just convenient.

For example my latest Rust creation provides a web socket server and gets data to feed those web socket connections from our NATS messaging server. These are the 'system' libraries it depends on:

Code: Select all

$ ldd target/release/conq_ws_server
        linux-vdso.so.1 (0x00007fffc2895000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdd9f3a0000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fdd9f390000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdd9f36f000)
        libgcc_s.so.1 => /usr/local/lib64/libgcc_s.so.1 (0x00007fdd9f150000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdd9ef80000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fdd9f812000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdd9edf0000)
Dynamically linked by the way.

Arguably all of that could be done in Rust instead. Seems kind of pointless to rewrite it all though, it's all tried and tested software and if it does not work your system is pretty much hosed anyway.

But what about that web socket and NATS stuff? If I was doing that in C++ I would be fishing around for web socket and NATS libraries, likely figuring out how to build those as libraries. Having to integrate them into my build system, make or whatever.

As it happened in Rust, I just name the crates in my Cargo.toml, they get downloaded and compiled, job done!
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 6290
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 7:46 pm

Sorry I thought my comment was not useful and deleted it.

I don't like any static linking nowadays because ....

Code: Select all

$ cc hello.c -o hello
$ ls -l hello
-rwxr-xr-x 1 jah jah 6320 Aug  9 20:40 hello
$ cc -static hello.c -o hello
$ ls -l hello
-rwxr-xr-x 1 jah jah 1075984 Aug  9 20:40 hello
1,075,984 bytes vs 6,320 bytes !!!
Furthermore, updates to the libraries are automatic and don't involve my program.
Secure code I guess must be statically linked to avoid trojans.

So the web socket stuff is statically linked for conq_ws_server? Fair enough.

By the way, you might like to try without -lrt (its contents are now in libc).

Code: Select all

linux-vdso.so.1 (0x00007fffc2895000)
The vdso stuff complicates things - popular system calls that don't involve a context switch and are very very fast.
Probably Rust gets to use those as the kernel adds the library gratuitously and the C library wrappers them.
Pi4 8GB running PIOS64 Lite

Heater
Posts: 16846
Joined: Tue Jul 17, 2012 3:02 pm

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 8:14 pm

I can totally appreciate the space saving idea of dynamic libraries. That is the whole point of them originally as far as I can tell.

I'm not sure the space saving is significant for my application code though. We have gigs or RAM and storage and any data we are dealing with is likely far bigger than the program!

Having libs updated with your OS is also an advantage. Provided that change does not break anything. At least for your operating system components.

Sadly if you are using a language other than C you end up using a bunch of libraries for that language that may or may not be provided with the OS and if they are can be massively out of date. For example Python modules or node.js modules etc, etc.... Better to have your own module system and get the good stuff, like PIP, NPM, Ruby GEMS and the Rust Create system.
Memory in C++ is a leaky abstraction .

ejolson
Posts: 6016
Joined: Tue Mar 18, 2014 11:47 am

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 9:05 pm

Heater wrote:
Sun Aug 09, 2020 6:55 pm
jahboater wrote:
Sun Aug 09, 2020 6:14 pm
That doesn't sound good for a "systems programming" language.
Hmm...

My idea of a "systems programming" programming language is a language that you can use on bare-metal devices, to build operating systems from scratch, and so on. In such 'systems programming' you have no libraries to depend on, static, dynamic or otherwise. See Linux kernel for example.
I suspect many people consider a systems programming language to be the one in which you would write the entire operating system not just the kernel. In a Unix-like environment this would include most of programs in /bin and /usr/bin.

Early versions of Unix did not use shared libraries and even the C-based seventh edition did not. Though the cal command

Code: Select all

$ cal 2020

                                2020

         Jan                    Feb                    Mar
 S  M Tu  W Th  F  S    S  M Tu  W Th  F  S    S  M Tu  W Th  F  S
          1  2  3  4                      1    1  2  3  4  5  6  7
 5  6  7  8  9 10 11    2  3  4  5  6  7  8    8  9 10 11 12 13 14
12 13 14 15 16 17 18    9 10 11 12 13 14 15   15 16 17 18 19 20 21
19 20 21 22 23 24 25   16 17 18 19 20 21 22   22 23 24 25 26 27 28
26 27 28 29 30 31      23 24 25 26 27 28 29   29 30 31

         Apr                    May                    Jun
 S  M Tu  W Th  F  S    S  M Tu  W Th  F  S    S  M Tu  W Th  F  S
          1  2  3  4                   1  2       1  2  3  4  5  6
 5  6  7  8  9 10 11    3  4  5  6  7  8  9    7  8  9 10 11 12 13
12 13 14 15 16 17 18   10 11 12 13 14 15 16   14 15 16 17 18 19 20
19 20 21 22 23 24 25   17 18 19 20 21 22 23   21 22 23 24 25 26 27
26 27 28 29 30         24 25 26 27 28 29 30   28 29 30
                       31
         Jul                    Aug                    Sep
 S  M Tu  W Th  F  S    S  M Tu  W Th  F  S    S  M Tu  W Th  F  S
          1  2  3  4                      1          1  2  3  4  5
 5  6  7  8  9 10 11    2  3  4  5  6  7  8    6  7  8  9 10 11 12
12 13 14 15 16 17 18    9 10 11 12 13 14 15   13 14 15 16 17 18 19
19 20 21 22 23 24 25   16 17 18 19 20 21 22   20 21 22 23 24 25 26
26 27 28 29 30 31      23 24 25 26 27 28 29   27 28 29 30
                       30 31
         Oct                    Nov                    Dec
 S  M Tu  W Th  F  S    S  M Tu  W Th  F  S    S  M Tu  W Th  F  S
             1  2  3    1  2  3  4  5  6  7          1  2  3  4  5
 4  5  6  7  8  9 10    8  9 10 11 12 13 14    6  7  8  9 10 11 12
11 12 13 14 15 16 17   15 16 17 18 19 20 21   13 14 15 16 17 18 19
18 19 20 21 22 23 24   22 23 24 25 26 27 28   20 21 22 23 24 25 26
25 26 27 28 29 30 31   29 30                  27 28 29 30 31

$ man cal
CAL(1)              UNIX Programmer's Manual               CAL(1)



NAME
     cal - print calendar

SYNOPSIS
     cal [ month ] year

DESCRIPTION
     Cal prints a calendar for the specified year.  If a month is
     also specified, a calendar just for that month is printed.
     Year can be between 1 and 9999.  The month is a number
     between 1 and 12.  The calendar produced is that for England
     and her colonies.

     Try September 1752.

BUGS
     The year is always considered to start in January even
     though this is historically naive.
     Beware that `cal 78' refers to the early Christian era, not
     the 20th century.
prints the calendar correctly for the year of the coronavirus, it was statically linked and consisted of only 3682 bytes. For comparison, the version of cal on the raspberry Pi is 24480 bytes and dynamically linked to eight other libraries including libpthread. I wonder what the minimal size would be for a binary in Rust to do the same.

In additional to removing the bit about "England and her colonies" from the man page, it would appear from the beginning that the GNU Linux a.out version of cal employed shared libraries at least well enough for a shared C library. These days making shared libraries using ELF in Linux with C is easy. How can I make a shared library with Rust?
Last edited by ejolson on Sun Aug 09, 2020 10:20 pm, edited 1 time in total.

ejolson
Posts: 6016
Joined: Tue Mar 18, 2014 11:47 am

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 9:27 pm

For a fair comparison, I grabbed the cal.c source from /usr/src/cmd in the seventh edition copied it to my Raspberry Pi and compiled it as

Code: Select all

$ gcc -Os -o cal cal.c 2>/dev/null
$ strip cal
which shockingly resulted in a working program of only 5655 bytes. However it was still dynamically linked to four other libraries. I tried static linking and obtained 419004 bytes, which is glibc crazy. For comparison, on an x86 Linux machine using the musl C library I obtain a static binary of 30136 bytes. As there are also musl-based Linux distributions for the Raspberry Pi, I wonder how many bytes cal would take in that case.

For reference, the exact code for cal.c that I compiled is

Code: Select all

char	dayw[] = {
	" S  M Tu  W Th  F  S"
};
char	*smon[]= {
	"January", "February", "March", "April",
	"May", "June", "July", "August",
	"September", "October", "November", "December",
};
char	string[432];
main(argc, argv)
char *argv[];
{
	register y, i, j;
	int m;

	if(argc < 2) {
		printf("usage: cal [month] year\n");
		exit(0);
	}
	if(argc == 2)
		goto xlong;

/*
 *	print out just month
 */

	m = number(argv[1]);
	if(m<1 || m>12)
		goto badarg;
	y = number(argv[2]);
	if(y<1 || y>9999)
		goto badarg;
	printf("   %s %u\n", smon[m-1], y);
	printf("%s\n", dayw);
	cal(m, y, string, 24);
	for(i=0; i<6*24; i+=24)
		pstr(string+i, 24);
	exit(0);

/*
 *	print out complete year
 */

xlong:
	y = number(argv[1]);
	if(y<1 || y>9999)
		goto badarg;
	printf("\n\n\n");
	printf("				%u\n", y);
	printf("\n");
	for(i=0; i<12; i+=3) {
		for(j=0; j<6*72; j++)
			string[j] = '\0';
		printf("	 %.3s", smon[i]);
		printf("			%.3s", smon[i+1]);
		printf("		       %.3s\n", smon[i+2]);
		printf("%s   %s   %s\n", dayw, dayw, dayw);
		cal(i+1, y, string, 72);
		cal(i+2, y, string+23, 72);
		cal(i+3, y, string+46, 72);
		for(j=0; j<6*72; j+=72)
			pstr(string+j, 72);
	}
	printf("\n\n\n");
	exit(0);

badarg:
	printf("Bad argument\n");
}

number(str)
char *str;
{
	register n, c;
	register char *s;

	n = 0;
	s = str;
	while(c = *s++) {
		if(c<'0' || c>'9')
			return(0);
		n = n*10 + c-'0';
	}
	return(n);
}

pstr(str, n)
char *str;
{
	register i;
	register char *s;

	s = str;
	i = n;
	while(i--)
		if(*s++ == '\0')
			s[-1] = ' ';
	i = n+1;
	while(i--)
		if(*--s != ' ')
			break;
	s[1] = '\0';
	printf("%s\n", str);
}

char	mon[] = {
	0,
	31, 29, 31, 30,
	31, 30, 31, 31,
	30, 31, 30, 31,
};

cal(m, y, p, w)
char *p;
{
	register d, i;
	register char *s;

	s = p;
	d = jan1(y);
	mon[2] = 29;
	mon[9] = 30;

	switch((jan1(y+1)+7-d)%7) {

	/*
	 *	non-leap year
	 */
	case 1:
		mon[2] = 28;
		break;

	/*
	 *	1752
	 */
	default:
		mon[9] = 19;
		break;

	/*
	 *	leap year
	 */
	case 2:
		;
	}
	for(i=1; i<m; i++)
		d += mon[i];
	d %= 7;
	s += 3*d;
	for(i=1; i<=mon[m]; i++) {
		if(i==3 && mon[m]==19) {
			i += 11;
			mon[m] += 11;
		}
		if(i > 9)
			*s = i/10+'0';
		s++;
		*s++ = i%10+'0';
		s++;
		if(++d == 7) {
			d = 0;
			s = p+w;
			p = s;
		}
	}
}

/*
 *	return day of the week
 *	of jan 1 of given year
 */

jan1(yr)
{
	register y, d;

/*
 *	normal gregorian calendar
 *	one extra day per four years
 */

	y = yr;
	d = 4+y+(y+3)/4;

/*
 *	julian calendar
 *	regular gregorian
 *	less three days per 400
 */

	if(y > 1800) {
		d -= (y-1701)/100;
		d += (y-1601)/400;
	}

/*
 *	great calendar changeover instant
 */

	if(y > 1752)
		d += 3;

	return(d%7);
}
which had a time stamp of Jan 10, 1979.
Last edited by ejolson on Sun Aug 09, 2020 11:10 pm, edited 1 time in total.

ejolson
Posts: 6016
Joined: Tue Mar 18, 2014 11:47 am

Re: Anyone using Rust on a PI ?

Sun Aug 09, 2020 10:42 pm

ejolson wrote:
Sun Aug 09, 2020 9:27 pm
As there are also musl-based Linux distributions for the Raspberry Pi, I wonder how many bytes cal would take in that case.
Okay, so curiosity demanded I compile cal.c on a Raspberry Pi using the musl C library. In a Void Linux chroot environment under 32-bit PiOS I obtained

Code: Select all

# gcc -Os -s -static -o cal cal.c 2>/dev/null
# ls -l cal
-rwxr-xr-x 1 root root 25804 Aug  9 22:36 cal
# file cal
cal: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=3be359b4505eeab52e0feaaa9bea45c2dc81c14d, stripped
# ./cal 2020

                                2020

         Jan                    Feb                    Mar
 S  M Tu  W Th  F  S    S  M Tu  W Th  F  S    S  M Tu  W Th  F  S
          1  2  3  4                      1    1  2  3  4  5  6  7
 5  6  7  8  9 10 11    2  3  4  5  6  7  8    8  9 10 11 12 13 14
12 13 14 15 16 17 18    9 10 11 12 13 14 15   15 16 17 18 19 20 21
19 20 21 22 23 24 25   16 17 18 19 20 21 22   22 23 24 25 26 27 28
26 27 28 29 30 31      23 24 25 26 27 28 29   29 30 31

         Apr                    May                    Jun
 S  M Tu  W Th  F  S    S  M Tu  W Th  F  S    S  M Tu  W Th  F  S
          1  2  3  4                   1  2       1  2  3  4  5  6
 5  6  7  8  9 10 11    3  4  5  6  7  8  9    7  8  9 10 11 12 13
12 13 14 15 16 17 18   10 11 12 13 14 15 16   14 15 16 17 18 19 20
19 20 21 22 23 24 25   17 18 19 20 21 22 23   21 22 23 24 25 26 27
26 27 28 29 30         24 25 26 27 28 29 30   28 29 30
                       31
         Jul                    Aug                    Sep
 S  M Tu  W Th  F  S    S  M Tu  W Th  F  S    S  M Tu  W Th  F  S
          1  2  3  4                      1          1  2  3  4  5
 5  6  7  8  9 10 11    2  3  4  5  6  7  8    6  7  8  9 10 11 12
12 13 14 15 16 17 18    9 10 11 12 13 14 15   13 14 15 16 17 18 19
19 20 21 22 23 24 25   16 17 18 19 20 21 22   20 21 22 23 24 25 26
26 27 28 29 30 31      23 24 25 26 27 28 29   27 28 29 30
                       30 31
         Oct                    Nov                    Dec
 S  M Tu  W Th  F  S    S  M Tu  W Th  F  S    S  M Tu  W Th  F  S
             1  2  3    1  2  3  4  5  6  7          1  2  3  4  5
 4  5  6  7  8  9 10    8  9 10 11 12 13 14    6  7  8  9 10 11 12
11 12 13 14 15 16 17   15 16 17 18 19 20 21   13 14 15 16 17 18 19
18 19 20 21 22 23 24   22 23 24 25 26 27 28   20 21 22 23 24 25 26
25 26 27 28 29 30 31   29 30                  27 28 29 30 31

Anyway, on ARMv7 compiling cal.c and statically linking with the musl C library results in a binary that is 25804 bytes. Woohoo! That's smaller than on x86.

Is anyone using Rust on a Pi?
Last edited by ejolson on Sun Aug 09, 2020 11:14 pm, edited 3 times in total.

Return to “Other programming languages”