[Toybox] Allow --help after other arguments?

[Rob Landley]

On 6/14/21 4:03 PM, enh wrote:
> On Sun, Jun 13, 2021 at 2:49 AM Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
> 
>     On 6/11/21 4:51 PM, Ryan Prichard wrote:
>     > On Thu, Jun 10, 2021 at 7:05 PM Rob Landley <rob at landley.net
>     <mailto:rob at landley.net>
>     > <mailto:rob at landley.net <mailto:rob at landley.net>>> wrote:
>     >     to show the help for ls. And DON'T want "chroot dir ls --help" to show
>     help
>     >     output for chroot. (Or time. Or nice. Or nohup...)
>     >
>     >
>     > Yeah, I think my ideal would be for --help to apply to the last (sub)command
>     > preceding it. e.g. When it appears after a subcommand name, it would be parsed
>     > like any other subcommand flag. For "time", flag parsing (for -p and -v) seems
>     > to stop at the first non-hyphenated argument.
> 
>     Which pulls in the argument parsing as a prerequisite for --help support in
>     commands like dd, expr, test...

FYI I've already figured out how to implement what Ryan wanted, I just haven't
done it yet because $DAYJOB didn't manage to make payroll this month and I'm job
hunting again. Bit distracting...

>     Sigh. It's possible this is an acceptable cost, I'd just really like to avoid it
>     if I can. It's that whole "project serving two masters" thing again. The
>     embedded space is weird. Yes you can fit the computing power of a supercomputer
>     into a wristwatch, at the expense of the watch's battery life being about 3
>     hours of actual usage and 12 hours on standby. My mental model has been the
>     "free toy inside" of a cereal box running two chips off a watch battery. A
>     modern version of the blinking LED that was in everything in the 90's. [1]
> 
> how much of toybox is even buildable (let alone usable!) without Linux or
> equivalent Unix-y kernel?

About a third so far? It's a bit like macos or bsd targets, you fix up for
whatever bare metal bindings you use. Linux itself comes with:

  https://github.com/torvalds/linux/blob/master/tools/include/nolibc/nolibc.h

Back when I maintained busybox I was immpressed when somebody ported it to run
bare metal with newlib+libgloss:

  http://lists.busybox.net/pipermail/busybox/2005-March/013759.html

But it's been 15 years since. Kinda got used to the concept. :)

> and afaik you can't run Linux [or equivalent] on any
> of the Cortex-M series,

I first ran linux on cortex-m 4 years ago for the contract at innoflight:

https://musl.openwall.narkive.com/Wi2diU8M/cortex-m-support

See:

https://www.emcraft.com/docs/linux-cortexm-um-1.14.3.pdf
https://github.com/mickael-guene/fdpic_manifest
https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg00533.html

> let alone the 8-bit AVR series or whatever else lives in
> the sub-Cortex-M realm?

One of the proposed marketing taglines for j-core was "32 bits for the price of
8".  (Technically it's a 16 bit instruction set with 32 bit registers...)

I started programming on a commodore 64 which had a 6502 (ok, 6510 but same
instruction set) which is an 8 bit processor with 16 bit addresses. (38911 basic
bytes free because the ROMs masked some, some memory ranges were used for system
purposes and I/O memory, and a whole 4k range at C000 was intentionally left
unused for non-basic machine code.)

I then bounced of Amiga and went to DOS with 16 bit register size (Turbo C,
"near" and "far" pointers, where "int" was 16 bits). My first big C program was
written in whatever they called the memory model that had 64k code space and 64k
data space (because it was faster by never having to to update the segment
registers).

I'm quite aware what you can do in that space. But to run modern posix-ish code
you really want 32 bit registers because gluing together two 16 bit registers to
make a 32 bit one is bigger code than just handling it natively. And gluing
together four 8 bit registers to get 32 bits is just painful.)

> (maybe things are different in the SH world? TIL^Wlast week i learned [when
> skeptical of your claim about generating the md5sum.c tables] that SH-4 has a
> sincos instruction! i don't know of any ARM cores with anything like that.

It's not that unusual, the 1980s intel FPUs (387 and 487) had trig functions
back in the day:

  https://mudongliang.github.io/x86/html/file_module_x86_id_115.html

Over in j-core land our GPS correlators have an internal CORDIC to calculate the
trig stuff:

  https://en.wikipedia.org/wiki/CORDIC

Radio signal processing is basically oversamping the expected signal and then
projecting a sin wave onto the data by rotating it around a sort of wheel in
order to interpret the data. Radio waves are basically sine wives, digital
samples are an array of integers, there's trigonometry involved in turning one
into the other. It's a pretty commmon thing for a DSP to do:

  http://www.techmind.org/dsp/

That said, a common way to implement this is with a lookup table of 45 degrees
of sin wave at whatever granularity you support, and then you map that around to
convert sin/cos and get the other 7/8 of the circle. But as long as that table's
already there in ROM... (The real question is do you get enough bits of
precision to calculate the numbers you want accurately...)

> sqrt is about as fancy as they get.)
> 
> and aren't the "free toy inside" crowd even _more_ likely to have one
> multiplexer binary than others? only folks with disk and memory to throw away
> will build n separate tools?

Yes, but I dunno what subset of commands they'll be trimming to, or what size
reduction surgery they might do to chop stuff out.

As I said, if I factor the --help and --version handling out into a function and
then call thet from within the the argument parsing logic _and_ have a fallback
in main.c that calls it for the no argument case, it shouldn't be too intrusive.
Might make a stab at that tonight...

Rob