Notices by Vertigo #$FF (vertigo@hackers.town)

So, I wrote a compiler for the 65816 in Rust. It has minimal syntax, and produces proven optimal code.

Of course, it only accepts a 16-bit signed or unsigned integer as input. Yes, integer. Singular.

But, it works, it's mine, and I'm proud of myself for writing it.

Thank you.

@alcinnz On the Z80, you had the LDIR and LDDR instructions to memcpy; on 8086, REP MOVSW.

The 68010 introduced "loop mode", so you could do the same with:

with comparable performance.

@alcinnz Without a cache, there's no need for data prefetch. If you could support the CPU's instruction fetch rate at full speed, you automatically could handle data access at maximum speed already.

@Faibbus @cancel The problem isn't applying clean code to a few floating point multiplications. I think that misses the point.

I think what he was trying to convey was the dogma that is clean code can be just as dangerous as premature optimization.

Like all things in software development, performance needs to be measured. OOP works great at course-grained modularity. The problem comes when trying to over apply the technique, which a lot of people do in Enterprise computing to structures that are quite small in scope. As someone who has had to maintain enterprise level software for several decades, I can confirm unbashedly just how difficult it is to work on large code bases that are extremely polymorphic. It is nearly impossible to work on such code bases without having some dynamic debugging environment active. It is nearly impossible to statically infer the correct behavior of a program just by reading the source code, which significantly impacts the ability to code review.

Now, Casey is talking about performance issues, and I'm talking about actual correctness issues. But they both have common roots: dogma.

@alcinnz The entire user experience is a travesty.

1. Number one, and in my opinion, the single most important detractor: No side-by-side comparison of patches. Hate to say this, but the line-oriented diffs are not ideal for making before-and-after comparisons of the code. In my experiments with SourceHut, it does not adequately address this concern.

2. No (topical) in-line feedback is possible without completely marring the content and legibility of the email. One could argue this is a good thing, as it strongly rewards making lots of microscopically-sized patches that are easier to review. However, I counter that with, in my day-to-day, I find tiny patches are a once- or twice-in-a-year phenomenon. My work typically results in large-scale changes that cuts across multiple layers in the technology stack, leading to large, wide-sweeping patches that must be applied all at once for things to work (e.g., drivers, kernel, language bindings, and the app proper). Use of email for patches just isn't useful for my current line of work.

3. Interfacing with e-mail clients assumes you run a mail client locally, and do not make use of web-mail or "integrated" mail clients like MS Outlook. Unfortunately, at work, we use Outlook and webmail interfaces depending upon need. My personal mail needs is also covered by webmail. Importing and exporting messages for use with Git is possible, but it is an additional burden which, bluntly, is remarkably error-prone if you don't pay attention to what you're doing.

I'm not going to say that it's superior or inferior to alternative methods; but for my current work-flows, e-mail patch management is just not a good fit. I'm sure it's great for those who have good supporting tooling surrounding their workflows, and for those who have teams who buy in to having tons of really, really tiny patches instead of a few rather larger patches.

At the end of the day, it all depends on the preferences of your team mates and the needs of the project.

Goddammit! Who else here remembers when towels were made of terry cloth that actually absorbed the fluids it was applied to, instead of just s m e a r I n g it all over the place?

I don't expect kitchen towels to sop up water like a shammy, but I do expect towels to at least pretend to try to dry things!

🤬

@seanmcbeth @davidgerard They relied heavily on such medieval techniques as maintaining customer support staff, user surveys, keeping an eye on outside support channels, etc.

But, we are in the renny-seance period now, so companies are better than that. All hail Big Data. Don't forget to rub Big Table's belly for good luck.

@alcinnz Very much so! But it is rewarding when, after a pile of hours invested, you finally get the "1+1=2" diagnostic you were looking for.

I was today years old when I got #Java, C, and #Rust to play nicely together in a project.

Oh, ...., that thing? That's the one nerve I have left. Why do you ask?

@alcinnz The fact that it's so easy to trap cats (in boxes) and that they frequently hurl, makes this decision much too difficult for me. ;)

So, as a result of @kenshirriff 's 8086 blog articles, I went down one of those infamous rabbit holes and studying the 8086 and 80286 bus interfaces.

I had remembered from an early Radio-Electronics magazine article and the 8088 Project Handbook that the 8086 had a, to me and at the time, weird way of selecting byte lanes over which data was moved. After all, the 68000 made so much sense with its separate upper and lower data strobes. What was with this "byte high enable" bullshido?

Turns out, they're exactly the same, and it's a matter of interpretation. On the 68000, _UDS maps to A0, and _LDS maps to _BHE (Well, _BLE really, since it would enable D7-D0, not D15-D8).

All this time, and here I was thinking that Intel's bus interface was somehow more complicated than the Motorola interface. It's not -- it's literally exactly the same (only the sense of which byte lane is enabled for odd and even addresses are swapped, since the 8086 is little-endian and the 68000 is big-endian).

Oh well; better late than never, I suppose?

I made a new blog-ish post on my website, regarding Uxn and FPGA implementation thereof.

Just for funsies, I've been thinking about how I would go about implementing
the Uxn virtual machine as a physical machine instead.

NOTE: I'm not committing to undertaking such a project. I just don't
have the time for it right now. This is more of a thought exercise.

http://falvotech.com/tmp-blog/20230124.html

@alcinnz @raccoonformality Avoid the Atari 2600 until you've mastered the 6502. The TIA chip doesn't have a frame buffer, so you'll be "racing the beam", as they say. So, not only does your code need to be logically correct, it must also be correct in time as well, and you'll need detailed knowledge of PAL or NTSC waveform generation.

I'd recommend using a regular computer from the 80s, something like a Commodore 64 or Atari 400/800 family of machines. Learn the 6502 on this platform first.

Then, once you're comfortable with that, I'd say you'll be ready for the deeper embedded world that dedicated games consoles tend to be.