This is a damning article re Pine64
As a firmware dev, I'd have quit too.
job search post, please boost
I’d like to try to get a job, I:
I am very experienced with low level development (especially in C and assembly for x86, arm and risc-v), especially in the context of drivers. I also have experience with embedded and especially bare metal development and linux porting on arm and risc-v.
More details in my CV: https://garnet.codeberg.page/cv-nolinks.pdf
Links for the mentioned projects contain sensitive information and will be provided on-demand.
religious fanaticism, Jehovah's Witnesses
I recently read (or maybe watched) the claim that the proselytising that Jehovah's Witnesses are required to do is not in order to convert anyone, it's the cult's way of ensuring members of JW feel isolated, alone and like no-one outside their community even listens to them.
Been thinking about it a *lot*, especially since Jehovah's Witnesses are often a punchline, and anyone mentions them paying a visit to say how they basically told them to eff off.
the specific problem with ABORT" is that i can't see how it passes the address of its string back to the exception handler. it looks like there's magic involved... which is a very bad look. you'd think that given the Forth Standard zeal for overspecifying everything else, they wouldn't have overlooked that...
i mean, it would even have made much more sense to define
: ABORT -1 THROW ;
: ABORT" POSTPONE S" POSTPONE THROW ;
and specify that the first 256 negative numbers are specific, system-defined exceptions, and anything else will be printed as a string by the top-level CATCH
...but then, there's a more fundamental problem: the definition of CATCH is wrong too. it takes a single xt, but it needs to take two, and only execute the second one if the first one THROWs. it's too late now, but maybe Forth needs a TRY that works that way
and having just read the standard definition of
THROW, which is supposed to be an ultralight exception handling mechanism...
If the top of the stack is non zero and there is no exception frame on the exception stack, the behavior is as follows:
If n is minus-one (-1), perform the function of 6.1.0670
ABORT(the version of
ABORTin the Core word set), displaying no message.
If n is minus-two, perform the function of 6.1.0680
ABORT"(the version of
ABORT"in the Core word set), displaying the characters ccc associated with the
ABORT"that generated the
no no no! what the hell were you thinking?! if you want THROW to double-time with ABORT. then ensure there is always a handler that does that, so THROW always lands in a matching CATCH; and if you want a THROW" to correspond to ABORT", then define one! don't overload THROW like this!
it's not that a forth standard is a mistake - it's just that the people in charge of it are profoundly mistaken
so it turns out that the current Forth Standard proposal is having some trouble with character literals. it defines the syntax
' where <ch> is any printable character... but the set of printable characters includes ascii 32, and if you type
' ' you get the xt of
...and this is why hardcoding literal recognition into the forth interpreter is just a bad idea, even if it stops at single precision integers! if you want a literal, define a word that parses literals and use that - that's the Forth way, even if it does mean you can't type
2 3 + . any more
i don't normally repost from twitter, but this caught my eye...
...mainly for the lack of self-awareness. that's basically what most software products look like WITH maintenance! without, they'd basically just be four rotten bits of wood...
the only issue i have with little VMs is that by necessity they waste about 80% of the CPU power they consume (on modern PCs with speculative execution). not their fault - there's just no way around that.
on slower, in-order machines with no branch prediction, the still lose about 80% of their cycles, but mostly to pipeline stalls (which don't consume a whole lot of power)
and put bluntly, power consumption is the only damn metric that means anything any more. lower is always better. (which is why this trend towards web apps is so fucking offensive to me, and frankly to the planet - instead of a little app with a local database sipping at its host's resources, we now have the power consumption of the browser on the local machine, the server farm on the other end, and all the networking equipment in between. set against that shitshow, a little VM wins without even trying.)
> We discover ÆPIC Leak, the first [...] CPU bug that leaks stale data from the microarchitecture WITHOUT using a side channel. [...] leaks stale data incorrectly returned by reading undefined APIC-register ranges.
> ÆPIC Leak is like an uninitialized memory read in the CPU itself.
What a wonderful time to be alive. https://aepicleak.com/
...because let's face it, it's pretty clear now that we're doomed. not least because none of the people who could effect meaningful change are even interested in acknowledging the problem, let alone finding anything approaching a solution.
just a rabbit caught in time's headlights
in case it's not clear from the contents of my timeline, i don't know anything about anything
(byte-and-iron level alt of @thamesynne - see profile there)
"if you torture data long enough, it will confess to anything"
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!