dd86k's blog

Machine code enthusiast

2023 Plans

Author: dd
Published: October 16, 2022
Last modified: December 25, 2022 at 15h02
Categories:

Join me while I attempt to talk about what I plan to do in the year 2023!

Using my Blog More

Because of my personal use with social media, progress done on my projects were published in small increments, but none of those updates were published on a slower, bigger platform such as this blog, which I wish to use more often in the coming years. And, well, I dislike forcing people to follow me on social media when it comes to personal projects.

I hope to write at least something quarterly, or at very best weekly (generic progress reports), at least something to put in your RSS feed and my Telegram update channel once in a while.

Also, yes, I will use this as notes for next year.

Updating my Themes (and Portfolio)

If you haven’t checked my GitHub Portfolio yet, you probably noticed that I have two theme projects that I made.

While I don’t use Windows as my primary operating system anymore (my older computer only could run Windows unfortunately), I don’t maintain my Notepad++ VS2012 Theme as much, but hopefully I give it a fresh update for next year and support more languages that Notepad++ supports. I still use Notepad++ at work, though!

And obviously, the other theme is the current WordPress theme. I’ll have to see how I can avoid putting the entire content on one side of the screen (no one complained yet, but it bugs me a bit) and update the CSS (e.g., using flexbox).

I’ll also have to update the content and styling of my portfolio.

Sunsetting alicedbg

While it is a cool project, the burden of maintaining various decoders (especially x86) is simply too much.

Having to efficiently decoding SSE, AVX, and AVX-512 instructions being the same with dozens of exceptions is something that drove me a little crazy.

What a chore.

There are even projects which solely specializes in decoding x86 instructions, including AVX-512 instructions with the MVEX and EVEX prefixes, as fast as possible. The engineering behind this is amazing by itself.

Yes, I could use an engine that can decode all kinds of instructions, but if I have to maintain C or C++ bindings on top of all this would be messy, so eh, no thanks. Still an awesome engine, though!

It would be too much work for solely the end goal of having a nice cross-platform debugger UI, but it was fun to implement various assembler syntaxes for it and learning how debugger works across platforms. I did find the object dumper somewhat useful at times, but isn’t really worth maintaining.

Trust me, you’re better off implementing a UI for GDB or LLDB yourself at this point.

Supporting 12th/13th Gen Core in ddcpuid

You know what annoys me? Intel implementing anything at all.

Why? I’m assuming they basically put their Atom SoC cores branded as E-Cores for their Alder Lake architecture.

Because, surprise! Their E-Cores don’t contain the information I need (at CPUID.1Fh) for making a cheap topology of the processor without traversing NUMA nodes. This means I don’t know how many dies are on the processor since ddcpuid is such a tiny executable and automatically runs on an E-Core, the information returned in CPUID.(ECX=2..5h)1Fh.EAX[15:8] is 0! Zero! And CPUID.1Ah.EAX[31:24] is… Not helpful.

Sadly, I have to depend on the operating system since I’m just a puny userspace program. Where’s the Linux equivalent to this? Sigh, what a chore.

Why doesn’t E-Core have the same content as the P-Core for CPUID.1Fh? Because yes, CPUID.1Fh has the exact same information as CPUID.Bh on E-Cores (even on the latest microcode, revision 0x22), rendering the whole thing useless without asking the OS to enumerate NUMA nodes. This project was supposed to be something portable!

I mean, yes, a hybrid configuration is a good idea for x86… Just not for desktops, at least just yet, with the current implementation. It’s a bit of a hassle for developers just to support the architecture, and there are already reports of some games performing worse on the architecture.

Do note that CPU-Z only supports Windows and requires Administrator privileges to run, so that makes it easier for them to support Alder Lake and Raptor Lake.

Worse yet, current 3rd Generation Scalable Xeons processors do not have this hybrid architecture, but instead have “high priority” and “low priority” cores (seems to be in frequency only), although this still makes up only one processor. And yes, Xeons still have support for SGX and AVX-512, something not found on Core processors as of Raptor Lake (13th Gen Core).

Because of this, I tell myself that if I fail to support this by the end of 2023, I will simply sunset this project alongside the manual.

Stay classy, Intel.

The Future of Manuals

I am always fond of a good manual and good documentation.

However, I’m currently failing to see which of my projects would benefit from having a PDF manual and HTML documentation is already easier to generate and maintain.

While I do plan to keep the docupdater script up-to-date, unfortunately, I have no plans to create new manuals for any of my projects.

Though, I was, at some point, learning a stack with pandoc with markdown and LaTeX cover pages. Didn’t go very far with that, though.

Perhaps for other projects, but who knows?

ddui and Learning OpenGL

Demo featuring the same windows of rxi/microui

Surprise! New project, because I’m slowly learning OpenGL for a game engine that I wish to make.

I have some progress done to clean and fix the codebase with some success. So far, the project has amassed 16 stars on GitHub, with already one fork.

I’m slowly trying to learn OpenGL 3.3 and possibly ES 2.0.

Hashes: BLAKE3 and SM3

I also wanted to implement additional hashes, but BLAKE3 has a Merkle tree structure and SM3 is big-endian, which makes them a little more difficult to implement.

Which brings me to…

ddh 2.0

While git’s subcommand syntax is cute and does its job, it is not a good fit for ddh. Simply because hashes are not commands (verbs), but more like, you know, just nouns.

So instead of ddh sha512 FILE, I think it’d be much better and intuitive to write ddh --sha512 FILE. This could potentially also allow multiple hashes to be used from a single invocation.

And yep, sometimes I don’t even remember some of the option switches that I even make.

Anyway, ddh 1.5 is planned to have minor additions before 2.0.

Can ddhx Finally be an Editor?

Hopefully!

So far, I made some decent progress on the cursor-based navigation.

Unfortunately, Microsoft’s newer Windows Terminal does not support character borders (but conhost/OpenConsole still does as well as any xterm-based terminal emulators), which forced me to use another background colour to differentiate between the main and secondary cursors.

ddhx across OpenConsole (conhost), Windows Terminal, and GNOME Terminal with a cursor navigation prototype

I hope to make a little more progress on 0.5 next year.

Error Codes and Documentation

The only thing I kind of really want to do is adding the Microsoft documentation onto the codes I’ve extracted and possible other MUI language files for more codes.

And also add everything into an SQLite database or similar. Right now, the file structure simply is just messy.

I do use my own website! It was useful at fortunate times.

Well, that’s it for now, folks.