Very cool and I like the idea of a "meta-assembler." The most-recent version of flatassembler (fasm 2) is built with fasmg which is also a "meta-assembler" of sorts, in that it also doesn't directly support a specific instruction set and instead is a very powerful macro assembler. I'm keen to check out functionality overlaps between the two implementations.
Oh neat! Thanks for the link, I hadn't heard of fasmg before.
It looks like fasmg builds up from the byte level, so it would only work for architectures that use 8-bit words. Torque builds up from the bit level, so it can assemble code for architectures like in PIC microcontrollers, using word sizes of 12 or 14 bits.
However, fasmg does allow a lot more control over the syntax of the language. The documentation shows some pretty powerful string manipulation that's used to parse real x86 assembler code, which makes sense given the purpose of it. Torque doesn't allow overriding the syntax to that degree, the macro invocation syntax is baked into the assembler.
One thing that intrigues me about fasmg is how it handles circular dependencies in expressions [0] (search for 'circular'). Currently in Torque it isn't possible to use a label reference inside a predicate, because the predicate evaluating one way could insert additional code, moving the label and causing the predicate to evaluate the other way [1]. But in fasmg it's possible to use the result of an expression as part of its own calculation.
Tomasz (of fasmg) added "one more quick thought" re: 8-bit word not being a limitation, he said that since fasm1 had macros for LZW compression [0] (from the assembler alone) and that this is even easier with fasmg the word length isn't a restricting factor with his design either. Cheers and thanks for sharing.
I reached out to the author of fasmg WRT your post and circular dependency interest and he pointed me toward two posts that he wrote very specifically to explain what he believes is unique to fasm/fasmg and allows to handle circular dependencies of many kinds. [0] Types of multi-pass assembly, and [1] related pitfalls.
Thank you so much! It looks like the issue I described is what he calls the 'oscillator problem' [0]. This is an absolute goldmine, I'm going to be reading for days.
One of the things that actually sold me aside from the repairability thing and all was their wikipedia page[0] where it says that "HMD is headquartered in Espoo, Finland, and is largely run by former Nokia executives."
I was rather hoping that it'd be more like the Nokia we all remember from pre-iPhones. Guess not.
It's basically an attempt to capitalize on the goodwill of the old Nokia. Headline products are nostalgia-fuelled feature phone remakes. Their Android lineup is indeed very meh.
First, tell Nokia you intend to contact the ACCC about this refund, as the device isn't "fit for purpose" if it can't store files greater than 4GB.
If they don't instantly change their tone (as many vendors do once you mention certain four-letter agencies like ACCC or ACMA...), then lodge a complaint with the ACCC.
Ingram in this case are just acting as a warehouse/drop-shipper, same as they do for Microsoft and various other OEMs.
... although our (Australias) Data Retention and 'Lawful Access' legislation is crap, at least the Consumer Guidelines still generally favour the public! :)
They have operations in Australia, so they'd be covered by Australian Consumer Law[0], which requires goods to be of "acceptable quality". IANAL, but I think you should have a good claim under that given most other phones support exFAT, and the deficiencies with FAT32.
A couple of years ago I did a "Terminal Video Series" segment that also highlights the runtime overhead of 12 other languages, C of course actually one of the best ones: https://2ton.com.au/videos/tvs_part1/
I was actually surprised for C how expensive that is, I'd expected maybe a dozen or so syscalls to set up the environment the provided runtime wants, but that's a lot of syscalls for not very much value. Both C++ and Rust are more expensive but they're setting up lots of stuff I might use in real programs, even if it's wasted for printing "hello" - but what on Earth can C need all those calls for when the C runtime environment is so impoverished anyway?
Go was surprising to me in the opposite direction, they're setting up a pretty nice hosted environment, and they're not using many instructions or system calls to do that compared to languages that would say they're much more focused on performance. I'd have expected to find it closer to Perl or something, and it's really much lighter.
glibc isn't particularly optimized for startup-time. It also defaults to dynamic linkage which adds several syscalls, and even if it is statically linked, it may dynamically load NSS plugins. (musl gets around the latter by hardcoding support for NSCD, a service that can cache the NSS results).
C11 adds several things that benefit from early initialization (like everything around threads), but GCC had some level of support for most of them before that.
I routinely don't want persistent mount points. Imagine my: cryptsetup luksOpen /dev/sdXY name
Followed by: mkdir -pv /dev/shm/name
mount -o noatime /dev/mapper/name /dev/shm/name
What this "RemoveIPC" did for me was rm -rf all of that, even if I mounted them as root.
That a single "RemoveIPC" difference between openSUSE 15.2 and 15.3, undocumented, caused me to lose all that data is one thing.
Another thing entirely to question WHY "RemoveIPC" is even a thing to begin with. I have never logged into any machine and said "wow look at all of this stale data taking up RAM in /dev/shm".
In fairness, that history seems to indicate that maybe it really was SUSE who decided to enable it. Sure seems like "RemoveIPC" option should have been advertised as a 15.2 -> 15.3 update repercussion. :-( :-( Leap 15.2 didn't do that, 15.3 does. Unknown what the other systemd distros do with "POSIX shared memory cleanup"
I also learned Z80 first, and I can say categorically that learning 16-bit x86 is NOT a good idea. To do anything useful in 16-bit, register starvation is a constant. Segmentation issues are actually hard problems.
I submit that if x64 existed early-on, no one would have bothered with higher-level abstractions. x64 is actually -pleasant- to code in natively.
I wrote a Linux general purpose library for x64 assembler: https://2ton.com.au/HeavyThing/ and in recent months I decided to start doing video tutorials about the "how and why" of same. Learning I think is made easiest in Linux by learning how to navigate the syscall interface and how "man 2 write" becomes an important skill. Edit: Videos link as well: https://2ton.com.au/videos/
https://board.flatassembler.net/topic.php?t=19389
https://flatassembler.net/download.php