Mastodon Feed: Posts

ireneista@irenes.space ("Irenes (many)") wrote:

so anyway we just got to the subtraction words in our review, and are trying hard to remind ourselves how it should be. heh.

ireneista@irenes.space ("Irenes (many)") wrote:

this is why the exercise we're doing now, of verifying that everything our code outputs matches up with the way we want it, is hard. we can't turn our brain off and do it by rote, we have to notice the similarities and differences of each case. fortunately we left ourselves notes, in the form of documentation on each Forth word, but it still takes a bunch of thought.

ireneista@irenes.space ("Irenes (many)") wrote:

and the assembly language, the human-facing notation, may end up differing substantially from the machine code, in regard to which is which

ireneista@irenes.space ("Irenes (many)") wrote:

especially when you contemplate that this same decision also occurs at the machine code level

in all of these instructions, there's two slots for a register identifier, and which is which is consistent across some operations and not others

jonny@neuromatch.social ("jonny (nonvenomous)") wrote:

we were just messing around in the sciop chat and the topic of running sciop on a vape came up somehow, and somehow we wound up with a custom vape skin, and i think one of my blessings in life is being around this caliber of high-effort low-audience irl shitposter day to day
https://blog.sciop.net/2026-09-13/sciop-on-the-vape

ireneista@irenes.space ("Irenes (many)") wrote:

and so designers of assembly language syntaxes have to choose, do you stick with your convention about where the target is, or do you stick with your convention about how it lines up with traditional math-on-paper notation?

since we're doing RPN, we have this a bit easier, but it's still a trap for the unwary

ireneista@irenes.space ("Irenes (many)") wrote:

but that feels backwards! with addition, multiplication, xor, etc, we can entertain the fantasy that the computer knows and cares about our notation, that it's as if we're writing out "rax + rbx" and it does the arithmetic and stores it into the second one

with subtraction, that assumption breaks

ireneista@irenes.space ("Irenes (many)") wrote:

well, in Evocation we made the call that the result goes into rbx, which because of the way Intel's instruction works, also means it subtracts rax from rbx

ireneista@irenes.space ("Irenes (many)") wrote:

what does this operation do, do you think? clearly it takes the values in rax and rbx. clearly it subtracts one from the other. clearly the result goes back into one of them. which order are they subtracted in? which one does the result go into?

ireneista@irenes.space ("Irenes (many)") wrote:

submitted for the approval of the Midnight Society

:rax :rbx sub-reg64-reg64

ireneista@irenes.space ("Irenes (many)") wrote:

have you spotted where we're going with this, yet? we suspect people who've spent much time in assembly have run into it before...

"add" is not the only operation that takes two inputs, one of which is also an output. there's roughly twelve of them, different arithmetic and bitwise operations with different carry behavior.

and humans have strong opinions on how these should be written, quite apart from assembly language

ireneista@irenes.space ("Irenes (many)") wrote:

but of course not every operation has a source and a destination, as move does. the "add" instructions have a source and a target. the distinction we're making here is that the source register and the target register both provide input, but only the target is modified.

:rbx :rax add-reg64-reg64

this is how we write the instruction that takes the value of rbx, takes the value of rax, adds them together, then puts the result back in rax

again, source before target

ireneista@irenes.space ("Irenes (many)") wrote:

Evocation is a Forth dialect, so things in it happen in reverse order, like RPN on a calculator. for example, in Evocation-assembly we defined a word mov-reg64-reg64 which is a move instruction, and you call it like

:rbx :rax mov-reg64-reg64

and what that means is, take the value from the register Intel calls "rbx", and copy it into the register Intel calls "rax". the source register comes before the destination register in our notation.

ireneista@irenes.space ("Irenes (many)") wrote:

so. the "move" instructions (intel calls them MOV) all have two parameters, a source and a destination. when the parameters are both registers, the instruction encoding, the actual machine code, necessarily encodes representations of both registers.

ireneista@irenes.space ("Irenes (many)") wrote:

haha, wow, sigh

so

we were reminded, through this process, of a weirdness about the concept of assembly language, which we first noticed earlier this year...

neatnik@social.lol ("Neatnik :prami:") wrote:

Working on an experimental Email-to-RSS thing. If you'd like to help test, hop on the omg.lol IRC server!

Boosted by cstanhope@social.coop ("Your weary 'net denizen"):
trashheap@tech.lgbt ("trashHeap :hehim: :verified_gay:") wrote:

Looking for recommendations for youtube or peertube #retrocomputing creators, who don't fill their content with LLM shit; and are not secret republicans? Thanks. #BoostsWelcome

Boosted by andrewnez ("Andrew Nesbitt"):
sunnydeveloper ("Emma Irwin") wrote:

I've moved Open Source Wishlist (oss-wishlist.com) to a stand alone teaching tool. It uses Ecosyste.ms metadata for critical OSS projects to help identify risk, intervention, and expertise required to mitigate that risk. It lives as evidence that - sustainability is an accountability and funding problem - NOT an information or talent problem.

https://sunnydeveloper.com/we-have-the-data-the-standards-the-expertise-to-solve-most-oss-sustainability-problems-dollars-not-so-much/

#opensource #sustainability

Boosted by pixxl:
robpike@cosocial.ca ("@robpike.io") wrote:

RE: https://mastodon.social/@dabeaz/117259349418891202

In the early 1970s, most folks could do some mental arithmetic. They had to. The arrival of pocket calculators quickly reduced most people's ability to do "math" in their heads.

Ditto with Google Maps: people can't navigate without it. A recent study of Polish radiologists using LLMs to assist showed a measurable drop in the doctor's own ability to diagnose without them

LLMs will have that effect on programmers' ability to code.

More broadly: for people to be able to think for themselves.

Boosted by pixxl:
robpike@cosocial.ca ("@robpike.io") wrote:

Our tech overlords believe that's OK. Maybe it is. I like calculators, I like maps. But I worry every day about what LLMs are doing to people's brains.

It's why I won't touch the damn things. I like my ability to think.

ireneista@irenes.space ("Irenes (many)") wrote:

so, having added that, now we're back to looking through the output for each assembly instruction and making sure it's correct

Boosted by cstanhope@social.coop ("Your weary 'net denizen"):
catsalad@infosec.exchange ("Cat 🐈🥗 (D.Burch)") wrote:

😭

ireneista@irenes.space ("Irenes (many)") wrote:

there's one more smaller feature we know we'll need in it, but it's an easy one

ireneista@irenes.space ("Irenes (many)") wrote:

okay. a thing happened that interrupted our progress on Evocation, so nothing moved forward yesterday, but today we've got our momentum back and we just added what we think will be the last difficult semantic change to the bootstrapping infrastructure.

Boosted by soatok@furry.engineer ("Soatok Dreamseeker"):
cadey@pony.social ("Xe :verified:") wrote:

Everyone should slow down AI development except for me

https://xeiaso.net/notes/2026/everyone-slowdown-but-me/?utm%5Fcampaign=mi%5Firl&utm%5Fmedium=social&utm%5Fsource=mastodon

Boosted by glyph ("Glyph"):
amcasari@hachyderm.io ("Yes, THAT commandasaurus 🦖") wrote:

If companies are testing in prod against your open infrastructure in a way you don't allow and it costs you anything you didn't agree to, ban the domain.

You have precedent and support to not be a fucking testbed for someone else's product dev.

https://arstechnica.com/gadgets/2021/04/linux-kernel-team-rejects-university-of-minnesota-researchers-apology/

Boosted by glyph ("Glyph"):
mhoye@cosocial.ca wrote:

Just thinking back to that time at Mozilla where we spent a staggering amount of time and effort on back-end systems that gave us cryptographic guarantees that our telemetry aggregation systems were privacy-preserving and robustly safe even in the face of infrastructure compromise, and these motherfuckers are out here like "haha oopsies we can't guarantee that an off switch that you switched to off is actually off really".

glyph ("Glyph") wrote:

What's this? An update for patrons!?!? https://www.patreon.com/creatorglyph/posts/patreon-update-169373024

jscalzi@threads.net ("John Scalzi") wrote:

It's time for me to come clean and admit it: At no time in my life was I ever, in fact, punk as fuck

Boosted by ireneista@irenes.space ("Irenes (many)"):
Em0nM4stodon@infosec.exchange ("Em :official_verified:") wrote:

Today @zackwhittaker brings up a very important topic about the launch of the new Apple Watch this week:

How a large company like Apple can play an important role in normalizing intrusive surveillance.

"Apple is opening the door to a world where other companies, device makers, and app developers try to recreate or rival Apple's technology and do a far shoddier job, all the while creating a worse surveillance monster and introducing new security and privacy risks along the way."

We don't talk enough about how privacy is also a culture, part of cultural norms that can go in one direction or another.

Products like this, produced and sold at a massive scale, weakens our culture of consent and privacy, and pushes society towards the increasing normalization of always-on surveillance.

I highly recommend reading Zack's article: https://this.weekinsecurity.com/watch-what-you-say-apple-opens-the-door-to-a-nightmare-world-of-always-listening-tech/

#Privacy #Security #Apple #MassSurveillance