On 6/14/21 4:03 PM, enh wrote: > On Sun, Jun 13, 2021 at 2:49 AM Rob Landley <[email protected] > <mailto:[email protected]>> wrote: > > On 6/11/21 4:51 PM, Ryan Prichard wrote: > > On Thu, Jun 10, 2021 at 7:05 PM Rob Landley <[email protected] > <mailto:[email protected]> > > <mailto:[email protected] <mailto:[email protected]>>> 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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
