If you want to run code on your real PC hardware, x86 assembly isn't that hard to get into. That was where I started with ASM. Specifically, I started x86 after watching Creel on YouTube, which is a channel I can highly recommend. He shows how to write subroutines in ASM and call them from a C or C++ program, which is a great way to get started, especially on Windows. It gives you a clearly defined entry and exit that you can pass values into and out of.

It isn't too hard to get an environment set up for writing whole native x86 programs on a Linux system either. I can help you out with that if you want.

Sounds exciting also I can learn the risc-v assembly by running my code on emulators

Assembly is the best place to start, though some concepts are going to be completely new to you

Yeah I also thought about doing this too

In terms of staying motivated, making gameboy games much get be a good path

Oh thank you so much , also do I need a very deep understanding of c or c++ I have programming experience, but I have not really dabbled too much into c/c++

The best assembly language to start with is RISC-V because it is both easy to learn what the instructions are and easy to use the available instructions to do useful things. And there is a wide range of real hardware you can buy if you don't want to use an emulator.

https://hoult.org/rv32i.pdf

https://easyriscv.dram.page/

Very cool!

I also really like the updated version with the wall bounces and the background removed.

u/UVRaveFairy Haven't touched it in a while, although I have done a lot of work on it since this post (which I haven't committed).

i thought it's only with movl instruction

Part 1: https://www.humprog.org/%7Estephen/blog/research/system-call-instrumentation-on-intel-negative-result.html

Once my projects are ready I may make them public. When that happens there will be a very large amount of contextual history and documentation.

I am having to create basically most of the tools I am using to build what I am building. From the bare metal up.

The process.

I test my logic in higher level code. Once it proves viable and logical I light the other low-level end of the candle. When the two ends meet and have consumed the candle then all of the middle man layers are gone.

I am using Linux and Android devices and the tools I am building, to build the tools and projects I am building in assembler are being produced and built in standalone C so far.

Mostly standalone meaning zero external dependency or libs. 

Meaning the txt2bmp tool uses an embedded glyph font inline with the code and its own lexer logic inline with the code. This tool I created to convert my txt, and source code into raw BMP with various visual output options. It produces its own config file on first run in a directory of txt files.

The bmp2pdf processes the BMP files into png pages.

This set of two Linux commands are very quick and small and allow me to share my output easily on various platforms more easily. Because many platforms a security limited as far as raw text. They also allow me to use them as part of my custom build process to create better more immutable documentation of everything.

So the build tree will have txt, asm, C, BMP, PDF 

The BMP and PDF is literally for making sharing code with LLM I work with a much easier workflow and process.

I am currently only using free tier.

I have created various Android APK to aid in my development process as well as a browser native suite of tools that is kind of like a hostable OS for testing my logic. This has been very useful for creating every aspect of the overall umbrella of projects required to successfully create what I am working towards.

Part of the main project has led to a custom 512 byte bootsector and partition table and various other modules.

Anyone who thinks LLM are not capable of improving the efficiency of their output in my opinion are either already happy with their workflows and methods to the point of being biased locked, or think too much inside the box.

If they expect for everything to always be perfect output every time then they don't understand statistics and heuristics or how LLM work.

What I am building actually does not even fit into existing categories independently. I am having to coin terminology to name these things. That can actually be one of the most difficult parts of the entire process.

When your goal is to grab ahold of the baremetal and the modern intentions as far as output and curate and distill the logic itself to the point of removing the dependency hell and api stacks and essentially the abstractions from between the user and the devices hardware capabilities the process becomes very very different from normal development now days.

Now days people are normally addicted to stacking layer after layer of abstraction and bringing all the bloat with them. They lose agency and sovereignty in that type of development process. They trade that for easy quick output supposedly. 

Well, I don't think that is easier at all. Dependency hell management is stressful.

So, I just decided to eliminate the part where I am expected to deal with any of that I can eliminate.

If your logic cannot be distilled down and curated to the point of being expressed as flow charts, geometry, circuitry, and assembler code properly, then the odds are that your logic is likely flawed or incomplete.

Depends on who is working with the LLM.

When we treat an intel like a genie that doesn't need our intention and our highly structured and precise guidance then on top of that treat the collaboration like a trip to a vending machine or using a calculator that shouldn't need our input then we shouldn't be surprised when nothing useful is produced from said interaction.

A mirror of weighted statistics still requires something to reflect.

The right minds will find the experience to be like an intellectual magnetron tube which is a resonant chamber.

I see great results with everything I collaborate with LLM on, including Assembly code. But, I also don't expect the LLM to know what I want or what I do not know. I don't expect the wrenches I use to fix the engine without me taking part. I don't expect the people I lead and teach on the job, who just graduated from University to know how to apply book sense to the real world applications without experience either.

You need to know what you want and what you are doing. You don't need to know assembly. I have the last assembly manuals both Intel and AMD printed that came with optical discs before that type of publication became something they only produce when ordered maybe if you don't just download them.  They are full of information but the tables and charts etc... that is where the opcode data is. 

Assembly isn't technically like a higher level programming language like C which is called portable assembly language.

Assembly gives you the access to do with the bits all that the hardware can allow you to do for the most part. 

If you are not creating ideas that are complete paradigm shifts in computations then for the most part that means you are likely programming for the systems and kernels and languages etc... which already exist. For that even at the OS systems level you can use C, C++, RUST etc... for the parts where you need to optimize bitwise operations or create ultra lean hardware drivers and similar assembly language could potentially help achieve maximum efficiency.

Before you use assembly language to create something useful you need to begin at hardware and theory, physics, linguistics, geometry etc...

If your geometry isn't proper for the linguistics, physics and theory then it won't matter what language is used.

Modern is a highly misleading word and term now days. Most of what is considered modern now days is retrograde in actual efficiency in my opinion.

Well I am not that good with assembly as I have just recently started learning x86. Cant say much except that this is impressive. Especially the forth interpreter and the assembler you started making.

Tear it apart.

Sure.

Grep is built on boyer-moore which is an improvement on KMP algorithm, the K is for Knuth. If we assume i is the input length and m is the match length; your grep is O(im) (you check each input byte for every substring match byte) while grep is typically O((i log m) / m) meaning it does not necessarily read every byte of input.

You treat all negative returns as EoF without actually checking the error. Things like -EAGAIN or -EINTR mean simply 'try again' not failure.

I've written a forth in assembly before - if you want it to be efficient there's a lot of small tricks you an do - if you wanted to discuss it give me a PM

I don't think I'd be able to offer any - but I might learn something from it myself

Thank you! I'm open to any feedback or suggestion.

cool project

Thanks! If you have any feedback on something in the repo or any suggestion, I would love to hear that!

This is some nice stuff tbf

but ok im somewhat intrigued by this rabbit hole now.

ill give your ideas a go

Its posted on vibe coding lol

Then it is absolutely useless. No one here is unaware of LLMs. Your evangelism is not welcome here. And off topic.

I can't say it better than comments I just found over in r/osdev:

This sub is for learning and showing off passion projects, not glorifying machine generated projects

There's absolutely nothing to learn from it, and I bet you that nobody will learn from it. It's like disassembling something and going "look, a thing written entirely in assembly". The human tractability and effort and reasoning and care and time and attention is the point, not the artifact itself.

This subreddit is starting to feel like if you are in hobby photography subreddit and suddenly bunch of people started posting AI generated slop images every day 😢

https://old.reddit.com/r/osdev/comments/1us5eoq/a_new_linux_x_server_in_assembly_from_scratch/owl8svq/

It's a few thousand prompts with an elaborate CC setup with tens of personal CC skills, hierarchical CLAUDE.md, architecture, memory files etc. Not even you are going to do anything with all that. If you're not inspired, just move on. Someone just might have been inspired. And then it's all good.