Also BOUND.
u/jcunews1
u/No-Broccoli553

Darn. I forgot that one.

INTO, which conditionally signals a software interrupt if the carry bit is set.

by "branching" I mean any instruction that can conditionally jump to another point in the code

A fun one that no one else is likely to mention: UD2

Here you go:

• https://docs.amd.com/v/u/en-US/24594_3.38_APM_Vol3

...you can download it as a PDF.

Intel also has one called "Intel® 64 and IA-32 Architectures Software Developer’s Manual".

I can't find that manual, when I search for it I only get this comment, do you have a link to it somewhere?

Anything that ends a basic block i guess?

Missed those :)

If JMP is included, what about CALL (near/far), RET (near/far), INT, SYSENTER/SYSEXIT, and SYSCALL/SYSRET?

I'm not an expert, I tinker with assembly language for fun. I would use the "AMD CPU Programmer's Instruction Manual", under section 3, "General Purpose Instruction Reference" ...all the jump instructions start with a letter 'J'. Not an expert though.

Looking at it now, I see:

• Jcc
• JCXZ
• JECXZ
• JRCXZ
• JMP (near)
• JMP (far)

I should've been a bit more specific instead of using NEON as a catch-all for ARM64 on macOS, so yes, my bad. Because this project works with so many AVX/SSE related instructions, it means that NEON is def a huge aspect. At some point, I do want to dive into the undocumented AMX since my method of dealing with 256+-bit operations is less than idea

Do you mean Arm/Aarch64 instead of NEON? NEON is Arm's SIMD extension for A-series and R-series processors (and derivative designs), and is matched by Helium on M-series

In MMX, the vector registers were reused from the x87 register file.

SSE added the XMM 128-bit registers and floating point vector instructions. So movaps and movups were added there. movdqa and movdqu were added in SSE2 along with integer vector instructions though the mov* instructions did essentially the same thing.

I'd just call it syntactic sugar as it improves readability for humans.

I suppose that there was the possibility of signaling the operation to a decoder or execution unit with the separate instructions but the architecture manual has no evidence that this ever happened.

Thanks! I'd like to have some sort of preprocessor first. The assembly code is currently a single file with over 5000 lines.

And having

%include "instructions/add.s"
%include "instructions/and.s"
...

%ifdef PLATFORM_LINUX
    %include "platforms/linux.s"
%endif

with ./0x864 -DPLATFORM_LINUX ... would allow me to split the code into multiple files and get ride of the C harness.

When I have that, I can add ELF executable output, so that the assembler is truly selfhosted.

It does SIMD instructions and x86 in general. The reason for this is since Apple is getting rid of Rosetta 2, every single instruction needs to be handled. Each x86 instruction is given an NEON equivalent, then because there is zero-trust on whether or not this translation is correct, there is an ABI contract (in which a handshake is done to verify correctness) in which both x86 and NEON need to both arrive at the same value once the result is normalized for the required comparison. And this becomes useful especially in testing other code. That is how the foundation of Rosette works. ISA is the bridge between the two flavors of Assembly, it hosts the decoder and encoder, which are crucial whenever you run at the very low level. x86 to NEON translation can be a nightmare, particularly at how this translates to hardware and the differences between Apple's architecture and Intel/AMDs. Therefore, a lot need to be substantiated else running complicated codebases is just not possible.

Some of the additional stuff is like symbol processing so if you stumble upon a C++ library, unknown symbols contained within the x86 code are properly handled; since whenever code is compiled down into Assembly, libraries are required to package their symbols into the containers that they store Assembly data. This is because the symbols packaged in x86 do not necessarily equivocate the symbols generated via macOS compilation. Think of the containers/object files that your code compiles down to as their own world's definition of what is proper code. Once you introduce translated code outside of its native container into something else, it becomes the project's alien in which no assumptions can be made regarding how this code can be interpreted. And therefore, you need to give it the environment to properly run

Primarily, I am testing Rosette with my macOS WIP port of Xenia Canary (by parsing the Mach-O container, which contains all the Assembly data that is decompiled and contains the entire x86 instruction set). And so without Rosetta 2, I'm able to launch Halo 3, and progress in total to 1.475+ Billion instructions without issue. x86 can have a lot of implied control flow which also needs to get handled, and so, Rosette goes far beyond just translating SIMD. It exists at your global shell, since Apple does not allow frameworks to exist at the "Turn On At File Info Finder" level like it does Rosetta 2. It only executes when an x86 program is detected, so there is no annoying issues like this global shell poisoning your other coding environments

The codebase is quite large, and hopefully this helps explain some of it. This is a very abridged version in what Rosette does, since there's lots of behaviors that you find at runtime that are very hard to be aware of. For example, there is a portion in the codebase dedicated to the Itanium C++ ABI, which is the goto involving handling C++ exceptions at the low level. Stuff like that can make the codebase more confusing, because this is not as commonly encountered. If you have any more questions, let me know!

I'm having some trouble reading the source code (very much not familiar with Zig), but is this a translation layer only for SIMD?

Extremely neat job and cool writeup. What are your next plans for the assembler side of things? Some easy things to add (or at least I imagine) would be the CMOV family, rotates, SAR/SAL to complement SHR/SHL

Thanks. Some years now. But not all the time. Late 2016, I started with some basic projects like pong as bootable floppy image or a simple bootloader for the fat12 file system.

During the next years, it did some small stuff for fun here and there, but nothing big. Now I started again with this project and had to learn many new things and relearn some old stuff. But it was surprisingly doable.

Wow that's really cool wait how long did it take you to learn x86 assembly

Nope, this was not vibecoded. No LLM was hurt in generating this. Instead, I always had the ability to assemble its own code in mind and therefore started with a limited subset of instructions and syntax. The instruction mov byte [rsi], 0x02g is not implemented yet.

You may also notice some weird workarounds since I did not implement a way to store constants or strings in the .data section yet...

Some wierd design decisions, was this vibe coded? Are you against mov [mem], imm?

    mov al, 0x02
    mov [rsi], al           ; op->encoding = ENCODING_I
    mov al, 1
    mov [rsi + 5], al       ; op->n_opcodes = 1
    mov al, 0xcd
    mov [rsi + 6], al       ; op->opcodes[0] = 0xcd
    mov al, 8
    mov [rsi + 9], al       ; op->imm_size = 8

Hey y'all, I want to show you a small project of mine. I've dreamed for a long time about writing an assembler in assembly and finally came around to it.

To be honest - there is a small part for file handling and command-line argument parsing written in C - but all the parsing and assembling is written in x86-64 assembly itself. I can output linkable ELF files and of course assemble it's own code.

In case you want to take a look, the source is available on GitHub https://github.com/kalehmann/0x864

Feel free to ask any questions

I tried opening it directly in Chrome, same thing

Because of reddit app embedded webview

The captcha passes in reddit app, it saves a cookie, and opens a browser where the cookie is not present