Machine Code Meddling and the Lower Levels

This is the thread for those of us who enjoy the machine codes, the assembler languages, and the rest of the lower levels our machines have. If you have any routines, techniques, tools, or anything else related to this wide topic, do post it in here. On that note, let this also be a thread for discussion of machine preferences. To encourage discussion, here are some questions: Do you think binary machines are the best or trinary or decimal or something else? Are you more inclined towards the hardware itself and prefer machines that can be specialized? What do you like most about the lower levels of your machines? What do you tend to do with it? Do you prefer virtual machines over a more general hardware bedrock? In light of recent events, let's try to compile resources related to this topic as well, considering that very specific information can already be hard to find at times.

Something I find hopelessly interesting is older video game systems, before they had internet-connected operating systems and heavy protection against anything you could get them to load and when the games had full control over the machine. Two systems I find interesting and would like to develop for at some point are the Virtual Boy and the Wonderswan. The Virtual Boy is in that bad place where there weren't many development kits and the market for flash cartridges is very small. Regardless, it's still got homebrew; it's not as if the released games can't be studied. It has an NEC V810 processor and I find it quite interesting. It's a RISC design similar to MIPS, but it has seven instruction formats and doesn't seem to have lived long enough to develop the cruft MIPS did. Even though it's more complicated in some ways, such as instructions being sixteen or thirty two bits, I can't help but find it cleaner in several ways. It also has bitstring instructions, included detailed documentation on unaligned penalties with these and whatnot. In short, it's an interesting machine. Unfortunately, the memory map for the system is more obscure than the processor and so this is one of the hurdles in development. It seems like most homebrew is written in a higher langauge. With the Wonderswan, there's an actual development kit that includes a C compiler I could study, but it would all be in Japanese, the documentation is sparse, and it's expensive. From what I can gleam, it looks as if the flash cartridge provided uses an extension cable hooked to the development machine through a serial connection and facilitates downloading the program onto the memory that way, which is novel when compared to how one would do it for something such as an NES. With all of this said, I'm trying to focus on CHIP-8 as of right now; at least it's well documented and easy to use. I'm working on a development tool for machine code programs and CHIP-8 will probably be the first platform supported, because of it's simplicity and actual need for tooling. I figured once I squeeze enough power and fun out of the CHIP-8, I can move on to these other systems and perhaps others, such as the GameBoy Color. I look forward to reading about your current low level endeavors. Once file uploading is fixed, I'll upload more documentation in my next post.

https://github.com/gurugio/lowlevelprogramming-university This was just posted on Hacker News, haven't looked at it much yet but might be good.

I always thought balanced ternary, but not much has been done with it besides that one old russian computer

>>43 i just started going through the art of assembly language, i got a soykafty pdf from the old pdf share thread going through it. think it's the old version. Anyone gone through that book before, is it good? better ones out there? i'm not going to use assembly language for programming, just looking to deepen my knowledge

Is there anyone working with Verilog/VHDL and FPGA? Where should I start if I want to design my own simple CPU and if I'm already familiar with computer architecture and digital logic on some intermediate level? Is it difficult to write a DRAM interface and simulate it?

>>488 I've had decent luck with this: http://www.fpga4fun.com/ I haven't done this one but I've heard it's good: http://www.nand2tetris.org/ Also here's a complete cpu in a couple hundred lines of verilog: https://github.com/jamesbowman/swapforth/tree/master/j1a

Where can I start?

>>814 Forgot to mention, Professional Assembly Language can be used to start delving into Assembly for those are already familiar with high level languages. Abrash's book was one of the go-to books for Assembly in the 90s. It targeted active users of Assembly, so I'm posting it more as a historic item. >>461 Try the #2 pdf.

>>799 I recommend you try easing yourself into a simpler machine code, such as ARM or MIPS, and see where you go from there. As for the lower levels of understanding, I recommend you start yourself off with reading ``Code: The Hidden Language of Computer Hardware and Software'': http://charlespetzold.com/code/index.html The work begins with introducing codes, electrical systems, and then moves to logic gates, timers, adders, and eventually an entire computing system. I believe you'll find it an interesting and worthwhile read.

Hey there, i'm having a problem with my program, i'm programming with debug on windows xp (shame on me), it's a homework... i'm having a divide overflow I'm doing it... n program u 100, 116 a mov ax, 5 mov bx, 10 mov cx, 3 add bp, ax add bp, bx add bp, cx idiv si, bp, 3 int 20 Someone?

reference: https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/debug_subcmds.mspx http://www.electronics.dit.ie/staff/tscarff/8086_instruction_set/8086_instruction_set.html#IDIV

I'm going to assume that the n names the program, the u gives some manner of metadata to the assembler or other tool, and that a is a label. It shouldn't matter that you're doing this for use under Windows, unless you need some manner of Windows functionality, which it doesn't seem that you do. Give a higher level view of what this program is to do, as it looks wasteful, currently. Also peruse some documentation concerning the IDIV instruction, which is signed; you may instead need to use the unsigned variant, DIV: http://x86.renejeschke.de/html/file_module_x86_id_137.html

>>76 So, as an update, I've been continuing work on my tool mentioned in this post. Here's an article I've written that details the tool, its origin, and design considerations: http://verisimilitudes.net/2017-07-07 Put simply, I've been lightly working on an interactive machine code development environment, with a simple and informative display, that's very customizable and based around the idea that you should press a key and have the tool aid you in writing instructions, to then give an informative view of things. Now, the CHIP-8 version has a Meta-CHIP-8, not yet described in its current state on that website of mine, and the virtual machinery is almost finished, but I can begin writing programs with it now to show the power of my tool. Here's the only screenshot so far, showing the tool asking a question, with a label, and a fresh program. I'd be very interested to get some opinions on this from you all. I've been discussing it in the IRC for months now and have recently taken to other places as well. I'd never seen anything resembling it in all of my research and neither has anyone else I've described it to. Of course, I also want this thread to survive. Machine code programming is so interesting and, since it's largely ignored nowadays, it's a good venue for novel research and whatnot.

>>7779 I read the post on your website, but I still don't see the benefit over just using an assembler. To me they seem like nonissues. For example if you don't like your code being in a write only section, why are you putting it in one? Can you elaborate more on what the advantage of your program is?

>>7783 >I read the post on your website, but I still don't see the benefit over just using an assembler. To me they seem like nonissues. I won't call that unreasonable. An assembler has conventions that must be adhered to for every little thing, mnemonics that must be memorized, macros that can't be changed, and other qualities I very much dislike. >For example if you don't like your code being in a write only section, why are you putting it in one? That's a fair point, but I also point out how an assembler just isn't amicable to self-modifying programs, as the numerical values are entirely hidden by the model. In my model, you can always look at what value an instruction has and the expectation is you may notice you can use an instruction as a numerical constant, rather than wasting space, say. >Can you elaborate more on what the advantage of your program is? Of course. So, as you've seen, the display model is simple and here's an example from the article: 0772-0773 304-305 1000000100100100 8124 33060 V1 <- V1 + V2; VF <- overflow This has much more information than an assembler ever would. Not only do you get the precise address for everything, but the numerical value and a precise description. The assembler language for this would, in comparison, resemble Add v1, v2 ; there's no indication of which holds the result; you must remember that register VF is changed every time to hold any overflow; in brief, the assembler language seems more concise, but also hides a great deal of information. Now, since my model is based on interactive use, you'd press a single button corresponding to addition, be asked for the first register, enter the number, do the same with the second, and then see that nice display; counting the enters, there's still actually less typing, even. Also note that this is merely how I would program it; there's no reason the addition instruction routine would need to strictly behave like this. I've also compared the information consumed per byte for my model, which is actually comparable to an assembler or better in many cases. Since I need to account for information in the smallest unit of memory, that means each byte has information for routines and names to be associated with it, even though it will be most common that only the first byte of an instruction has this. So, using a name would resemble Add name, v2 ; this consumes twelve bytes, not counting the newline. My model for CHIP-8 requires five bytes and one bit for each byte, since each nibble has name information, which consumes twelve bits here; for a two byte instruction, that's ten bytes and two bits. You can see that my model actually consumes less space here. Now this isn't counting where the name is actually defined, but my model only consumes 3+n bytes for a name, where n is the length of the name, as two bytes are the value and the last is the name length and other information; it seems fair to write that most name declarations in an assembler would consume more space than that. I've also seen the failure models of many assemblers and find them disappointing. My tool specifically avoids many failure modes, inherently. As an example, an ARM assembler will abort if an invalid ARM immediate value is requested. With my model, however, that simply can't happen, since I'm writing byte values and I can't possibly write something that isn't a byte. I even plan to have a special numerical input mode for ARM immediates with that targeting, to further ease things. I also can't suffer typical name failures, since the tool won't let you specify a name that doesn't exist and will simply scrub information if you use a name and later delete it. If you write a routine that handles names differently, you can still easily have it immediately alert the user to the issue, rather than fail later down the line. This, I believe, is a good explanation of some of the advantages of my tool. What do you think? I'm working to finish it so I can use it in the hackathon on the anniversary, so I'll probably have it ready for others to use soon.

>>7788 >You can see that my model actually consumes less space here. Are you talking about disk space for the "source" file? Let me try to summarize your program to see if I understand it. It's an interactive editor for writing your flavor of assembly. The editor displays a binary representation of your assembly in real time as your are editing your file. By offering an editor which is not just a regular text editor you are able to offer greater reliability that the written program is valid / correct. Is this an accurate description of what you are doing?

>>7791 >Are you talking about disk space for the "source" file? Yes. >Let me try to summarize your program to see if I understand it. >It's an interactive editor for writing your flavor of assembly. Yes; I'm currently targeting CHIP-8, but intend to target many other machines in the future. >The editor displays a binary representation of your assembly in real time as your are editing your file. It displays a numerical representation of the range of data (typically a single instruction), along with some other information, and a programmable representation of the data, intended to be read by a human. So, with that earlier example, you see the 8124 instruction in many forms, but it's also displayed as V1 <- V1 + V2; VF <- overflow , for a human to read. >By offering an editor which is not just a regular text editor you are able to offer greater reliability that the written program is valid / correct. I suppose that's one way to look at it. There is no such thing as a syntax error. The tool helps write each instruction and other data. So, yes. >Is this an accurate description of what you are doing? I suppose. I believe it will be more easily understandable once it can be used by others.

>>488 If you're using Verilog/VHDL it would probably easier just to make a SRAM array.

>>76 >>7779 I'd love to be able to do what you're doing. I remember seeing your original post back in 2017 and thinking how cool it was. I wish I was smart enough to mess with old game consoles. Seems really rad.

I hope some of you can enjoy.

>>7779 As an update, I have a version of the tool working, albeit not yet easy for others to install. I intend to greatly improve its article, but the current state can be found here: http://verisimilitudes.net/2018-08-08 Some details have changed; metadata only consumes 3.5 bytes for every byte of target data, now. I was mulling the issue over and realized there was a single instruction, DXYZ, that would actually be able to make use of nibble granularity and that this didn't justify the cost. Further, I've thought of an additional improvement of sorts that can lower the metadata to 2.5 bytes, but with a heavier cost I'd need to consider. Asides from that, I've now been using the tool to document already existing CHIP-8 games, since I can't start mine until October if I want to enter them in the Octojam. You may find the first such documented game here, chosen because it was so simple that I wouldn't have a section on an improved version: http://verisimilitudes.net/2018-08-18 I discuss it more in this post: >>10144 Lastly, here's a view of the tool, with the annotated game entered, in cool-retro-term, because I've recently downloaded that and it's fun.

>>584 nand2tetris is pretty fun, but the hack assembly language is really goofy if you already know MIPS or 6502 or Z80, it has weird syntax.

REAL RISC-V HOURS WHO UP ??

Do any of you guys know any C to Assembly converter that actually produces humanly readable code? I'm really stuck with this god forsaken language and need help, thanks.

I recall TempleOS had some nice feature like that. It's a huge meme though so I'm not sure if it'll serve you well

https://godbolt.org/ This one.

>>10677 gcc -S

>>10687 This Also, anyone got a good book for x86 assembly? I've written some basic programs with it but I'm looking to expand

I forgot to say, but it's not x86, it's MIPS assembly

>>10690 There are a lot of x86 assembly books and they all focus on userland programming using almost always some kind of high-level assembler without using important x86 extensions (SSE, VT-x). I wish there was a good book for bare machine x86 programming.

>>461 The book is a little crap imho. It's better as a reference. From my own experience: To learn ASM, write it. Write lots of it. Everything will make sense after that. >>488 Look up a self paced course called NAND2Tetris. FWIW most FPGA people don't build entire CPUs. It's more common to use soft IP to get a pre-made CPU and alter it to your needs. The part of the equation you didn't mention, and you may be interesting in sharpening is developing the needed background in digital logic design. The electrical engineering aspects of this may take some extra study. >>1600 I disagree that ARM and MIPs are necessarily easier to learn. The barrel shifting stuff can throw people for a loop. >>10677 Learn to read compiler generated code. You'll need that skill eventually. It never corresponds 1-1 with the C-source anyway. >>10706 Because bare metal programming, and ASM programming are two different topics. You will not make it through day one of writing a boot loader without the ability to read manuals and write assembly language independently. You will be going back and forth to the intel manuals constantly during that kind of coding. No book can easily distill that experience. Things get very specific.

>>10145 To update again, I've made a good amount of progress on my MMC since. The primary article has been updated with a new image and video and can still be found here: http://verisimilitudes.net/2017-07-07 I've changed the display some, making it narrower and showing the code as CHIP-8 sprites, which is better. I've not changed the implementation much, as I've been more wanting to use it, having gotten this far. I'm unsatisfied with my Common Lisp implementation, however; Meta-CHIP-8 was a tangent, although it taught some lessons. I'm planning a simpler reimplementation in Ada: the tool will be more efficient, particularly regarding memory; more reliable; and easier to distribute. This Ada implementation will have it simple to reuse components and make targeting other architectures much easier. While I'm very interested with an MMC that is implemented in and customizable with its target machine code, that must be regarded as a less important aspect than rest of the tool itself. I have been thinking lately about a 6502 implementation, as that would be small and reasonable to do with if I wanted to run it on a 6502 machine. As for that OctoJam, I had other obligations and I spent around twenty minutes on the final day entering a fizzbuzz, fresh, into the tool for submission. As a bright side, this is the first and only fizzbuzz in CHIP-8 I'm aware of and it fits in a rather compact one hundred and four bytes. Pictured are my latest three documentings since my last update; the first one has also been updated; here are the links, in order: http://verisimilitudes.net/2018-11-01 http://verisimilitudes.net/2018-08-28 http://verisimilitudes.net/2018-12-12 Having done this, I've become very interested with documenting machine code programs; it's very fun to understand a program instruction-by-instruction. This has made me change my mind about a batch mode for the tool that has it output, say, TeX for nicely typesetting machine code programs. I'd like to move to larger programs, such as an Atari 2600 game I have in mind, and have nice books that simply explain a program in its entirety. I find that a pleasant idea. I've also considered that it would be an invaluable reassurance, to have a machine code program documented in detail and its entirety in a book that can't be changed, although this doesn't apply to games much. This nicely typeset machine code will apply when I begin work on the manual, once I finish the Ada reimplementation. Lastly, feel free to tell me what you think.

The atari programming guide is a good book. It's really enlightening. Worth a read even if you don't plan to program in it.

>>11811 You mean the atari compendium or some other book? I came across a few.

What I would really love, if there were a "simplified technical english" equivalent for x86, like a nominated subset of the ISA that lets you do everything you need to, to get started, even if it's not the most efficient or smartest way to achieve it, but you can focus on structure without having to refer to massive opcode lists and try to figure out which is the right one to use every call

>>11844 that's almost always what you do when hand writing assembler anyway. One of the reasons compiled code tends to be faster is it can make use of obscure opcodes.

>>11813 Good question... The one I remember reading was short and it may have been, but it could have been this long one https://archive.org/details/ataribooks-atari-graphics-and-arcade-game-design but maybe neither. It's interesting how graphics are drawn, how you only have limited time to update graphics in the vblank. You have to choose between reading input or more graphic power. All sorts of stuff. And technically it still applies on modern computers. Seeing limitations helps take away the magic I think. I dont remember everything but I remember it felt enlightening. Anyways I also found this new book

>>488 I just started learning verilog, just made a little led matrix game of life to practice programming in verilog. When learning a hardware description language, it realy is like learning programming all over again because everything you have learned about programming in the past is kinda useless, allthough, when you get the hang of it, it is all pretty doable.

I am taking a MASM assembly programming class called computer organization using the 8086 intel cpu and our current book really is like kicking dead whales down the beach for learning it. Can you guys suggest me some good resources specifically for MASM? I would prefer it to be youtube vid tutorials but if you got a good book or pdf to use that is not made by Irvine I would appreciate it.

I'm going to merge this thread with the thread already for this topic: >>43 Alternatively, you could just make your post there, without an irrelevant image, and I could delete this thread. Also, I'd ask your teacher if you could use, say, FASM, which is apparently well-documented and isn't proprietary.

>>12779 Oh yeah go for it and merge. I tried to ask my professor if we can use NASM but he was very anal about it being this piece of soykaf windows garbage where you have to load in Irvine's libraries to even make it work.

>>12780 >I tried to ask my professor if we can use NASM but he was very anal about it being this piece of soykaf windows garbage where you have to load in Irvine's libraries to even make it work. What? NASM is cross platform its not only for windows. To top that I didn't had any problem in installing it on a windows machine. Its sound like your profesor is full of soykaf or he was thinking about something else then you did.

>>12784 Yeah this is some community college I am attending cuz its cheaper to take it there than at my university. Get what you pay for I guess, lol.

>>11805 Well, I've been updating about once every four months, it seems. This time it's only been three months, though. It's a shame to me this last update got no thoughts. I've not made too terribly much progress since last time. I've been more concerned with actually using the tool than continually working on it, but at the same time I'm not sufficiently motivated to hunt down and correct some odd flaws, as I still want to abandon this implementation of my idea that currently exists, yet that then prohibits me from writing more complex programs in the tool, as I've envisioned them, because I'd also like to test the new implementation of the tool with such a writing. Currently, I'm still working on the Ada implementation, also giving some time to a complete Common Lisp reimplementation sharing no code, and have made some slight improvements to the tool's design or output. I'm not yet proficient in Ada enough, but I'm making very slow progress, and I'll likely have an unrelated program in Ada finished first. I've also decided to largely abandon a compressed format for the metadata, in part due to complexity concerns, in part due to other design considerations, and also because the size is still utterly negligible and, in all likelihood, may be served almost as well by a generic compression format. I've not abandoned it entirely, but it's just not important right now. Perhaps I'll soon take a diversion by writing a tool to generate, say, TeX based on the games and metadata and see how that works out. In any case, here's a new documenting: http://verisimilitudes.net/2019-03-03 Lastly, these attached images are new.

Hello, I'm looking for a device and documentation to develop a deeper understanding of the computer programs I write. My primary concern is pedagogy, rather than learning a system that is relevant. As such a system with a simpler set of instructions, which is easier to make interesting assembly programs for, and which has good learning materials available would be ideal. Additionally I'm interested in having a small physical device to run these programs on if possible. I'm aware that it is unlikely that a perfect device and documentation exists, and what I'd like to ask you is what device and documentation do you think makes the best compromises for the purposes of learning? Thanks for your time. Attached is a book suggested by http://www.loper-os.org/?p=13 which I have yet to read. It's on non-Von Neumann architectures, hardware optimizations for higher level languages, and similar things which might be of interest to others here.

>>14059 >I'm looking for a device and documentation to develop a deeper understanding of the computer programs I write. I'm the fellow developing the CHIP-8 development tool. Due to this, I have a bias towards recommending CHIP-8; it's a rather simple instruction set, designed for interactive and graphical programs, with a small memory space. With all of this, it's very easy to get something simple working optimally, as there's fewer than fifty instructions and several are quite specific, and you won't create something unmanageable since it's limited to 4096 bytes, with the first 512 being reserved. >My primary concern is pedagogy, rather than learning a system that is relevant. I was interviewing with a defense contractor recently and my interviewers mentioned that they, coincidentally, use CHIP-8 for teaching new employees, after I'd told them about my tool. I don't think I'll be getting that job, but that's besides the point. >As such a system with a simpler set of instructions, which is easier to make interesting assembly programs for, and which has good learning materials available would be ideal. Here's one resource I enjoyed; there's more to it, though: http://mattmik.com/files/chip8/mastering/chip8.html As for development tools, I'd love to be able to recommend mine, but I suppose I can't in good faith, at least currently, as I'm the only one who can really use it. I'd also need to update the files if I knew someone wanted to use it, since it's currently outdated with what I have. There is a development tool called Octo, but it's an abstract assembler and I don't believe you'd really get what you're looking for with it. You could always do what the original programmers did and write out your games by hand, though, or with a hex editor to make it easier on you in these modern times. I've written programs like this before; it's good for you. I used Emacs hexl-mode, but this isn't really convenient to use due to the default keybindings; I was simply too lazy to use a specialized tool and got around it by mostly using M-x hexl-insert-hex-string, but you can easily lose some input doing this if you're not careful. >Additionally I'm interested in having a small physical device to run these programs on if possible. I'm aware that it is unlikely that a perfect device and documentation exists, and what I'd like to ask you is what device and documentation do you think makes the best compromises for the purposes of learning? I suppose you could use an HP-48 series calculator for this, but even I've not bothered to do that yet. You're likely best off using a little emulator; Octo doubles as that and you may not be as averse to using JavaScript for this as I am. >Thanks for your time. It's not an issue. I'd be interested in seeing what you create, in any case.

>>14069 >CHIP-8 is a rather simple instruction set, designed for interactive and graphical programs, with a small memory space. With all of this, it's very easy to get something simple working optimally, as there's fewer than fifty instructions and several are quite specific, and you won't create something unmanageable since it's limited to 4096 bytes, with the first 512 being reserved. Well, that does seem pretty ideal. >Here's one resource I enjoyed; there's more to it, though: http://mattmik.com/files/chip8/mastering/chip8.html That is quite short, I should be able to write a simple program by Monday which is very nice. I'll start digging for some additional documentation after that point I suppose. >As for development tools, I'd love to be able to recommend mine, but I suppose I can't in good faith, at least currently, as I'm the only one who can really use it. I'd also need to update the files if I knew someone wanted to use it, since it's currently outdated with what I have. You could always do what the original programmers did and write out your games by hand, though, or with a hex editor to make it easier on you in these modern times. I've written programs like this before; it's good for you. In this case what I'll do is type my programs in hexl-mode until your development tool is ready for general use, both gaining the learning experience and not dedicating time to learning macros and what not just to switch later. >You're likely best off using a little emulator. The preference for a physical device was almost entirely just because I thought it would be neat. A emulator seems more sane for the moment anyway in that I don't have to go through the process of uploading my files to the device. >Octo doubles as that and you may not be as averse to using JavaScript for this as I am. I'm willing to use Javascript if it's necessary, but it seems there are many emulator alternatives which are worth looking into. >It's not an issue. I'd be interested in seeing what you create, in any case. I look forward to finding out as well, I think I have some ideas already. Thanks again.

I've a new documenting; it's also available over Gopher: http://verisimilitudes.net/2019-06-23 I've reached chapter twenty-four of my Ada book, which covers containers and which I don't particularly need, with the later chapters covering other parts of the language I'm interested in, but also don't quite need for this program. Chapter twenty-three covered the standard predefined library and now I do feel well-equipped to write Ada programs, already writing a few trivial programs and whatnot, so far. I'll probably end up writing a Finger and Gopher server in Ada before I do much else, though. In any case, if I fail to write an Ada version of my tool by the end of this year, I'll simply get the Common Lisp version in a decent state, instead, so that there will be at least one version of the tool available by the end of this year and perhaps much sooner. I've decided on a change to the metadata format, also; the format currently used requires three and one half octets for each octet of the program and the original format I'd devised and explained here, but so long ago I believe it was never implemented, used five and one eighth octets; my new format uses two octets by discarding the last of the extreme generality caused by that Meta-CHIP-8 tangent and halving the number of permitted names from 2^12-1 to 2^11-1. That will be nice, having such efficient metadata. I'm looking forward to having a good submission to the OctoJam this year, as I only submitted a fizzbuzz for last year's event, albeit the only CHIP-8 fizzbuzz I'm aware of.

What do lainons think about LLVM? Anyone working with it lately? I want to do something using it as a compiler backend but I feel lost on where to start with it. I have a good grasp on x86 assembly but LLVM feels odd to me. >>315 Can personally vouch for the first book here, it was really good. http://pages.cs.wisc.edu/~remzi/OSTEP/ This is also a nice introduction to OS concepts.

>>14155 >What do lainons think about LLVM? I think of it as a My first compiler playset. >I want to do something using it as a compiler backend but I feel lost on where to start with it. I have a good grasp on x86 assembly but LLVM feels odd to me. If you want to write a compiler, you could write, say, a simple Forth. Here's a nice and small Forth written in x86 assembler: https://github.com/nornagon/jonesforth/blob/master/jonesforth.S That this is a github link is regrettable, so here's the same file attached to this post.

>>14075 I just thought I'd briefly comment on my last response. >That is quite short, I should be able to write a simple program by Monday which is very nice. I'll start digging for some additional documentation after that point I suppose. I didn't actually end up needing more documentation than was provided, that's just it other than techniques so far as I can tell. >In this case what I'll do is type my programs in hexl-mode until your development tool is ready for general use, both gaining the learning experience and not dedicating time to learning macros and what not just to switch later. I wound up just editing ASCII which was then parsed to hex values by the interpreter I'm using: https://github.com/danirod/chip8 Attached is the progress I've made so far on a Pong clone I've been working on. All the game play is there currently, it's just a matter of adding some polish, like displaying the score, and adding delay for timing. I've been optimizing for speed as best as I am able, and I think I've been successful in doing this. I've really enjoyed reasoning about speed in machine code as because instructions in the execution path is such a good measure.

>>14174 I finished this a while back, I've just been a tad disconnected.

>>14153 What's Finger? I've never heard of it. I assume it's some kin of hypertext protocol?

>>14153 I've a new CHIP-8 documenting, involving my second public CHIP-8 program: http://verisimilitudes.net/2019-08-18 This is a Rule 30 implementation in CHIP-8 and, while not as good as it could be, I'm planning to improve it for the OctoJam, since I didn't want to wait any longer. I'll soon start on another program, a small tennis game with which I'd like to make use of self-modifying code to make it even smaller and reuse segments; since CHIP-8 has somewhat clumsy memory access, this will require some trickier programming to compress the self-modifying code into contiguous locations and so avoid unnecessary waste. As for Ada, I've continued with that, but haven't done too much Ada programming, lately. I have some of the primitives finished, but not the most complex; I'll probably end up finishing a great deal of the work in one day, when the mood strikes; I'm unfortunately still far too fuzzy on the internals of the tool, meaning I won't be able to organize it particularly well, yet. It's still going to be leagues better than my Common Lisp, however, since that was a mess of globals because I simply didn't care for making it organized with that. Perhaps ironically, I did improve the Common Lisp version a tad, with regards to display, and that's mentioned in the aforementioned documenting. >>14814 The Finger protocol is RFC 742: https://tools.ietf.org/html/rfc742 Put simply, it's a protocol for listing users and seeing what they've been doing lately. I'm aware John Carmack used Finger as a log of sorts, but I never looked into the particulars much. I'm using Finger to have a record of my work, too. You can access my finger server like this under UNIX; you may need to use netcat instead of nc here: printf 'Prince-Trippy\r\n' | nc verisimilitudes.net 79 | less I also have a little hack that makes it available over Gopher, but you probably don't know what Gopher is either, so check here if you're curious: >>4914 >>14782 I can see this is a Tennis game of sorts; would you like any thoughts, beyond making use of subprograms with the 2XXX and 00EE instructions?

>>14851 >I can see this is a Tennis game of sorts; would you like any thoughts, beyond making use of subprograms with the 2XXX and 00EE instructions? I'm sorry I never replied to you, I've been subsumed by the poverty of student life, among other things, and forgot I had posted here recently. I'm aware of many things I could do to improve that program already and I don't feel it would be a worthy use of your time to request suggestions until I've resolved those things. I appreciate the offer though, and I hope to take you up on it in the future. >I'll soon start on another program, a small tennis game with which I'd like to make use of self-modifying code to make it even smaller and reuse segments; since CHIP-8 has somewhat clumsy memory access, this will require some trickier programming to compress the self-modifying code into contiguous locations and so avoid unnecessary waste. I look forward to seeing your take on things! I remember struggling to think of how one would go about doing effective meta-programming in CHIP-8 a while back. >I've a new CHIP-8 documenting, involving my second public CHIP-8 program: http://verisimilitudes.net/2019-08-18 I was actually reading A New Kind of Science while I was starting to learn about CHIP-8. What a funny coincidence. Anyway I enjoyed reading your documentation, hopefully I can exploit your other documented programs to a further degree soon.

>>14851 I've another CHIP-8 documenting, related to the last: http://verisimilitudes.net/2019-10-05 This is an improved implementation of Rule 30 in CHIP-8, written for the OctoJam VI. I've only lightly started on that Tennis game, weeks back, but I may end up starting anew and finishing it in time to submit it as well. If not, I'll get around to it later. I'm not going to wait around as I foolishly did with this last year. As for my MMC, I did finish a good amount of the work as the mood struck, but regarding the Common Lisp implementation instead. I believe I'll end up getting the Common Lisp into a respectable state and only later finishing with the Ada for an optimized and more final version. >>15145 >I'm sorry I never replied to you, I've been subsumed by the poverty of student life, among other things, and forgot I had posted here recently. That's not an issue. I'm only getting around to responding to you now. It would be nice if this thread were more active; I'd like for more people to find the lower levels as fascinating and worthwhile as I do. >I look forward to seeing your take on things! I remember struggling to think of how one would go about doing effective meta-programming in CHIP-8 a while back. As a minor note, metaprogramming and self-modifying programs are two different things, although metaprogramming requires homoiconicity to be good, I think. >I was actually reading A New Kind of Science while I was starting to learn about CHIP-8. What a funny coincidence. That is a neat coincidence. >Anyway I enjoyed reading your documentation, hopefully I can exploit your other documented programs to a further degree soon. I anticipate it.

please i need help with converting high level code to DOS assembly: code in Processing language: void circle(float xc, float yc, float x,float y) { point(y+xc,x+yc); point(x+xc,y+yc); point(-x+xc,y+yc); point(-y+xc,x+yc); point(-y+xc,-x+yc); point(-x+xc,-y+yc); point(x+xc,-y+yc); point(y+xc, -x+yc); } void setup() { size(1000,1000); //stroke(255,128,0); //background(192, 64, 0); } void draw() { float xc=200; float yc=500; float r=100; float x=0; float y=r; float d=3-2*r; while (x!=y) { circle(xc,yc,x,y); if(d<0) { d+=4*x+6; x+=1; y+=1; } else { d+=4*(x-y)+10; x+=1; y-=1; } } } it draws circle basically: here is my try with assembly (warning: spaghetti ahead!) .386 DATA1 segment X DW 0 RDW 100 Y DW 100 XCDW 200 YCDW 500 DDW 0 P1DW 0 P2DW 0 mov ax, 0 add ax, ax mov D, 3 sub D, ax color DB 0 DATA1 ends CODE1 segment ASSUME cs:CODE1, ds:DATA1, ss:STACK1 START: mov ax,seg STACK1 mov ss,ax mov sp,offset top mov ah,00h mov al,13h int 10h mov ax,0 int 16h jmp PROG PROG: mov ax, Y add ax, XC mov P1, ax mov ax, X add ax, YC mov P2, ax mov color,15 mov cx,1 mov ax, X add ax, XC mov P1, ax mov ax, Y add ax, YC mov P2, ax mov cx,1 mov ax, 0 sub ax, X add ax, XC mov P1, ax mov ax, Y add ax, YC mov P2, ax mov cx,1 mov ax, 0 sub ax, Y add ax, XC mov P1, ax mov ax, X add ax, YC mov P2, ax mov cx,1 mov ax, 0 sub ax, Y add ax, XC mov P1, ax mov ax, 0 sub ax, X add ax, YC mov P2, ax mov cx,1 mov ax, 0 sub ax, X add ax, XC mov P1, ax mov ax, 0 sub ax, Y add ax, YC mov P2, ax mov cx,1 mov ax, X add ax, XC mov P1, ax mov ax, 0 sub ax, Y add ax, YC mov P2, ax mov cx,1 mov ax, Y add ax, XC mov P1, ax mov ax, 0 sub ax, X add ax, YC mov P2, ax mov cx,1 loop: mov AX,0A000h mov ES,AX mov AX, P2 mov DX,320 mul DX mov dx,P1 add ax,dx mov di,ax mov AL,kolor mov ES:[DI],AL loop petla Less: mov ax, 4 mov bx, X mul bx add ax, 6 mov D, ax inc X inc Y jmp After mov ax, D cmp ax, 0 jl Less mov ax, 4 mov bx, X sub bx, Y mul bx add ax, 6 mov D, ax dec X dec Y mov ax, X mov bx, Y cmp ax, bx je PROG mov ax,0 int 16h mov ah,00h mov al,03h mov dl, D mov ah,2 lint 21h int 10h mov ax, 4c00h int 21h CODE1 ends STACK1 segment STACK dw 256 dup(?) topdw ? STACK1ends ENDSTART so loop is basically equivalent of point function, it writes pixel to P1,P2 which are overwritten by combination of x and xc, and y and yc. First 8 instructions that looks like mov ax, 0 sub ax, X add ax, XC mov P1, ax mov ax, 0 sub ax, Y add ax, YC mov P2, ax mov cx,1 are 8 points function calls, so its entire "circle" function, then it goes into while loop. My program seems logical for me, but it goes into infinite loop. It seems i cant even enter 10h graphical mode, every time i input key (16h syscall) i get error in status window: "Illegal write to address: x". HELP PLEASE

>>15766 gcc can convert C code to assembly using the -S flag. Maybe that will help.

I've been thinking about how difficult it would be to develop a x86 to RISC-V recompiler (/linker) for Linux ELF binaries along the lines of how Dolphin does ppc to x86 recompilation. Essentially it translates the ppc code into equivalent C (or cpp? I can't remember) and compiles that with whatever system-specific compiler exists. There's a lot of room for cases where we are calling into functions we already know about (like malloc/free and much of libc) and we can just substitute that code with the real thing. Obviously there'd be issues when trying to load programs that use JITs themselves (like the JVM, V8) in which case it'd break horribly. But for a lot of programs that ship as compiler binaries this might work pretty well. It'd probably introduce timing side channels so any cryptographic functions like in OpenSSL would have to be special cased like libc. Also it'd just be faster to do it that way anyways.

So I've skimmed across some assembly courses and they all say something along these lines "Learning assembly will teach you think that will take you years to discover if you're working with higher level languages" but how truth is this and are those things that one can learn? Game and engine development are what interest me so is there anything to win form learning assembly for an old machine or x86 or am I fine with learning C?

>>15797 If you know C reasonably well then learning assembly won't be *that* hard to do. It's mostly taking every thing you do in C and thinking through the steps your CPU would need to do to make it happen. "I have a pointer to a struct made of 3 ints and I need to get the 3rd one, how do I do that?" Of course, you add 2*sizeof(int) to a copy of the pointer, then dereference that memory location. Now you extend that to manually implementing function setup/cleanup, and it's pretty neat. If you want to help yourself out with game development then maybe try out rolling your own 4x4 matrix multiplier using vector instructions.

>>15866 I heard about this, that C and asm have a close relationship. Maybe I don't need assembly and just need a good book on how C works with my machine's architecture. Or maybe I should learn assembly but don't need to actually use it. I'm unsure what's good now.

>>15765 I've another CHIP-8 documenting: http://verisimilitudes.net/2019-10-30 I wanted to write a game which was small, simple, and captured the essence of CHIP-8 and copying a little phone game from over a decade ago worked out rather well for me. As you can see, the game is only forty octets, with nineteen instructions and two data octets. As for my MMC, I've nearly finished an initial rewriting, so once I've the prime loop working I'll be able to test it and stomp out flaws as I notice them. >>15766 I really hate that I can't be of more help here, but I'm rather ignorant of MS-DOS and x86. Since you've the high-level code for this program, have you disassembled what your compiler gives yet? One way I can contribute is to highlight this; aren't these two fragments equivalent: mov ax, 0 sub ax, X add ax, XC mov ax, XC sub ax, X >>15786 Binary recompilation is a fairly old topic, so I recommend researching into prior art. I came across a paper discussing this from the 1980s, although I don't believe I actually had time to read it with everything else I was doing. >>15797 >Learning assembly will teach you think that will take you years to discover if you're working with higher level languages I'd think this would depend on if you're working with this as a first language or not. Learning an assembler language or machine code directly will teach you how the machine actually works at the lowest-level exposed to the programmer. You'll learn how complex data is decomposed into units the machine can operate on more easily, how subroutines are implemented, and other such things. >Game and engine development are what interest me so is there anything to win form learning assembly for an old machine or x86 or am I fine with learning C? I don't recommend learning C, you'd be better off with a higher-level language, but I also don't see much value in using the lower-levels just to write a game engine in this way, unless you're wanting to do something similar to what I've been doing. You'd likely be better off using an abstract and higher language to write one and, once you understand those fundamentals, learn more about how they're implemented later. >>15866 >If you know C reasonably well then learning assembly won't be *that* hard to do. It's mostly taking every thing you do in C and thinking through the steps your CPU would need to do to make it happen. I'm having flashbacks to when I went to an assembler language IRC channel and everyone only wanted to discuss C. The C language will teach you how the PDP-11 worked; not even modern RISC machines only expose functionality that C uses. The underlying machine can have bitstring instructions, saturation arithmetic, instructions dedicated to specialized patterns, a non-uniform memory space, and many other things C has no concept of. >I have a pointer to a struct made of 3 ints and I need to get the 3rd one, how do I do that? >Of course, you add 2*sizeof(int) to a copy of the pointer, then dereference that memory location. I'm not going to check a reference, but don't x86 and ARM have single instructions that can accomplish this, x86 by an index argument to a certain instruction form and ARM through its barrel shifter? There's also the knowledge that, if you will need those other two integers, you may be better off with a register load straight from memory, or if you'll later need them doing this and not touching the registers so another routine can avoid a load at all. This manner of thing is an essence of optimizing machine code, I think. >>15892 >I heard about this, that C and asm have a close relationship. They don't. This is a meme that's several decades old. The C language also lacks access to functionality such as SIMD instructions and even something as simple as a logical count is pattern-matched with a very specific form of loop so compilers can attempt to optimize it. >I'm unsure what's good now. I've given advice in my direct response to your earlier post. In practice, you'll probably want the majority of a game engine to be in a high-level language and optimize certain parts of it with handwritten assembler language or machine code. There are many different languages which are perfectly capable of linking to machine code, not just C, however, and you shouldn't really be concerned with this if you've never written a game engine before. Did my advice help at all?

>>15895 >I'd think this would depend on if you're working with this as a first language or not C is my first language and z80 assembly the only other I've seriously dwelt in >You'll learn how complex data is decomposed into units the machine can operate on more easily, how subroutines are implemented, and other such thing I've seen that, I've done some z80 exercises taking data from an address, moving it to the cpu registry and putting it on another address, it is tedious but I get the gist of it. >I don't recommend learning C, you'd be better off with a higher-level language Like what? >but I also don't see much value in using the lower-levels just to write a game engine in this way Thinking about this I need a good book on how graphics work to see how should I approach the thing I want to do and then I'll know what the best course of action is >They don't. This is a meme that's several decades old Based on your other replay seems like C is only closely related to whatever cpus where there in the 70's >Did my advice help at all? Yes thank you.

>>15896 >C is my first language and z80 assembly the only other I've seriously dwelt in Knowing that, I think you'd still have plenty to learn from machine codes, yes. As for a higher-level language, I've grown to like Ada, but that may not be the best language for you; there's a game engine named Xelf written in Common Lisp, but you'd need to familiarize yourself with Common Lisp in order to use it. You could use any higher language, really; even writing a game engine in Flash would likely teach you something. >seems like C is only closely related to whatever cpus where there in the 70's It's the PDP-11, yes. Other machines had a hardware notion of arrays so they could check bounds implicitly, a hardware notion of errors so that every higher language could use the same mechanism and also respond to hardware errors, and also things such as tagged memory so the machine only needs one addition instruction and can internally dispatch based on the numbers given, say. Of course, C lacks all of this because the PDP-11 does. I'm glad my advice helped.

>>15895 the thumbnails looks exactly like a screenshot from dwarf fortress with a river in the middle and woods on the left.

I was rereading http://verisimilitudes.net/2017-05-07 the other day and the memory-to-memory, cache-control, and memory interfaces of the desired architecture reminded me of many-core CPUs with scratchpad memory. These ideas seem like they mesh together so well I can't help but wonder if the author accidentally solved the problem of cache coherence, or this was planned all along and simply not mentioned. A commonly recognized insidious optimization is pipelining and out-of-order execution. The solution traditionally proposed is VLIW/EPIC which radically simplify the architecture while giving more power to the programmer. The architecture the authors described also removes a further significant degree of complexity introduced by EPIC, register renaming difficulties are completely removed, and speculative cache management is replaced with programmer control. Concerning branch prediction I recently found the following paper [0] which seems to be a extremely promising, beautifully simply alternative. In all honesty I'm not sure how well it would actually work with a memory-to-memory architecture considering memory usage, but it'd probably be fine. How elegant a modern machine could be made from these technologies. I'm not sure this is entirely inline with the authors intentions, but this tangent is beautiful to me. [0] http://webspace.ulbsibiu.ro/adrian.florea/html/docs/CAN_2003.pdf

Attached to this post is a rendering of a new documenting I've recently written: http://verisimilitudes.net/2019-12-31 >>16261 >I was rereading http://verisimilitudes.net/2017-05-07 the other day and the memory-to-memory, cache-control, and memory interfaces of the desired architecture reminded me of many-core CPUs with scratchpad memory. I'm glad I'm able to discuss my work with a reader. I intend to soon heavily rewrite and freeze my 2017 articles, to ease their maintenance. Would you link to resources concerning one of these machines, so I can tell if I'm already familiar with them or not? >These ideas seem like they mesh together so well I can't help but wonder if the author accidentally solved the problem of cache coherence, or this was planned all along and simply not mentioned. It's difficult for me to recall with any reliability my mindset when writing that, but I'll attempt to. Clearly, register machines seem the most popular, so much so as to become an insidious optimization; followed by stack machines; then yet others; and it seems memory-to-memory machines receive the least attention of them all. I believe neglected subjects are fertile ground for research and novelty, so this is part of why I decided to pursue thoughts of memory-to-memory machines, also being because they seem rather the most innate machine type. I found cache largely unnecessary, at least for this design, but I considered it trivial to add it to the system in this way, getting a more general mechanism that's controlled by the programmer; the closest resemblance that comes to mind is the quality of the PDP-6 in which the first sixteen memory locations were mapped to normal memory, but generally faster, and so tight loops could be written and executed in them; this may have been an inspiration, but I don't recall. So again, with cache, I disregarded it until everything else in the proposed design was finished, but when I did mull it over I tried to only consider something I could look at as reflecting an ideal, as I tried with the rest of the design. >A commonly recognized insidious optimization is pipelining and out-of-order execution. Perhaps I should mention these in the article, but I don't really consider these insidious optimizations, since people can and do still easily consider machines lacking these. The optimization only becomes insidious when it ceases to be recognized as such. >Concerning branch prediction I recently found the following paper [0] which seems to be a extremely promising, beautifully simply alternative. I gave this paper a decent read through and I'll be puzzled if the techniques therein aren't employed to varying degrees in the modern, awful processors. It's a neat and perhaps obvious mechanism. >In all honesty I'm not sure how well it would actually work with a memory-to-memory architecture considering memory usage, but it'd probably be fine. How elegant a modern machine could be made from these technologies. You've mentioned that primary issue with memory-to-memory machines, which haunts me, memory usage. It seems stack machines are truly the most concise, or at least close, considering there exist some with five-bit instructions, purely due to the implicit stack. The desire to have a simple and consistent machine format is at-odds with space usage and flexibility; a three-address machine would be nice, but costly, and a one-address machine would be hindered, but smaller. This is farcical in some ways, however; on my website, I've a review of Alan Turing's Electronic Brain and the ACE machine and derivatives used thirty-two bit instructions, having a billionth or trillionth of the memory a modern machine contains, and so an instruction two or four times as large, but with so many orders of magnitude more memory to store them, arguably isn't an issue in any way. The aesthetics of larger instructions still hit, however. I've experimented with one memory-to-memory design in which the instruction length was twice the address length, with one full address, a relative partial-address, and the remainder of the instruction dedicated to control, and this worked well enough, although it was gimped by other aspects of that particular design. As the memory grows, having a partial-address becomes less of an issue, as even a sixteen-bit space is still more than large enough, whereas the experimentation had a twelve-bit address with an eight-bit reduced address and a variant with two eight-bit addresses, to cannibalize the remaining four bits for a larger instruction set. Another interesting quality of this design were two instructions, which would translate between an instruction and an easily-manipulated field, to permit easy self-modifying code; the DEUCE ACE-derivative had something like this, but purely because the design lacked any indirection and whatnot and it was much less general, I don't believe it influenced this part of my design at all, but it's still neat. >I'm not sure this is entirely inline with the authors intentions, but this tangent is beautiful to me. My intent was to experiment, identify and enlighten others as to an insidious optimization, and try to make memory-to-memory machines more appealing through my research. If I've missed anything or you'd want to continue this conversation, I'll gladly do so.

I've been getting into assembly a little lately with Gameboy ASM, and boy its really been doing my head in. It feels so paranoid, like nothing I ever write can be elegent unless I copy it from somebody elses ROM. I dont think its helping that the Gameboy didn't have offset addressing modes and everything I think of wants to use them. Gimme some nice words lainons Im losing faith in my ability :(

>>17808 Programming at this low level is like solving a puzzle. You want to do a certain calculation or trigger a piece of hardware, and you have certain constraints with this-and-that representations of data and so-and-so ways to manipulate it. Your goal is to find the best way to cause the transformation of state desired with these puzzle pieces. There's no shame in seeing how others programmed the machine; the professional programmers for these machines did this when they saw an effect and wanted to mimick it. As long as you're making some progress, I wouldn't be worried about where you're at now.

>>14153 >. I'll probably end up writing a Finger Is it still being used? I have seen a lot of people using Gopher, but Finger seems to be as dead as it once was.

>>18848 >Is it still being used? Yes. I updated my Finger info just lately. There's now a year's worth of notes available from it. >I have seen a lot of people using Gopher, but Finger seems to be as dead as it once was. Finger is a nice alternative to social media garbage. It's just sending a line to a server and getting a response, and I keep notes in mine. It's possible and trivial to transparently access Finger servers over Gopher, because the two protocols are so similar. Also, I'm working on another little CHIP-8 game, looking to release one a month; I want to make little games which serve as proofs of the concept in a very small size, and then perhaps expand on them later; I'm going to try to have it ready by the end of this month, so I'll make a post if I do.

>>18887 >I'm working on another little CHIP-8 game Do you intend to try the same thing for something that is not CHIP-8 later? On your first post >>76 you did say you want to move to other systems later one, but maybe you forgot it given that you are really enjoying doing these things(and the posts on your site are really nice, thanks!).

Well, that game didn't happen. I got it into an almost-working state, but became bored fiddling with what were the final details to perfect the small core. It was one hundred and ten octets, which doesn't seem bad until compared to my last CHIP-8 game at forty, and which could be a full ten smaller if timing code and explicit constants were removed: >>15895 As for the MMC, I've recently started working on that again, and I've reached the stage where I can start writing instruction sequences with it. It's largely been in this state for months, but I was lazy and haven't hooked up many of the commands yet, but it's getting closer to an end state. Everything about this reimplementation is better, most visibly by using a redisplay model that eliminates much of the flicker, without avoiding redraws where convenient. >>18888 I still intend to target other architectures. I'm simply doing right by CHIP-8 before I move on. I could've chosen other, simpler targets, but CHIP-8 was actually very good for me, as it gave me a real reason to review programs already written, which showed me the value my tool has in inspecting and not just creating anew; the experience has taught me some commands I want to add at some point. I don't want to bait with future work which may not occur, but if I decide to start and finish an MMC for an extremely simple architecture before finishing CHIP-8, soon, this is the notice. >(and the posts on your site are really nice, thanks!). I'm flattered. I truly appreciate the praise. Just yesterday, I finished rewriting my 2017-07-07 article, the first MMC article. I threw away several paragraphs, and it's much smaller and more concise in other ways as well. I'd be interested in seeing what anyone else is working on and giving some thoughts. I don't want the thread to mostly be me and my work. Machine code is an underappreciated topic. On that note, I read of and watched a video for this small demo released recently; how interesting sizecoding hasn't been mentioned yet; I prefer optimizing for size due to its inherent qualities, whereas optimizing for speed no longer has such traits for common machines: http://www.sizecoding.org/wiki/Memories

I've been reluctant to continue posting in this thread, because I found it poor that I'm one of its main posters, along with wanting to take the time to write a large and proper post, yet not finding that time. This is only the eighth post in this thread all year, so far. Quite a bit has happened since my last post, but I'll be brief. I've finished reimplementing my Meta-Machine Code targeted at CHIP-8 in Common Lisp, and released this on the third anniversary of the original announcement: http://verisimilitudes.net/2020-07-07 gopher://verisimilitudes.net/12020-07-07 I've continued to improve it since, and it now has a command that automatically associates names to instructions, where this is valid. So, as an example, I may now name the address XXX and tell the tool to associate all 0XXX, 1XXX, 2XXX, AXXX, and BXXX instructions with the name. This is primarily intended to be used for documenting code already written, being much less error-prone than the manual method, and allowing me to even blindly name addresses I believe to be used and scan around for any associations. This was something too hard to add to the now-old version. The latest public version doesn't yet include this command, however. The display has changed, even since then, as this image shows. Notice the nice underlining of name associations. I'd considered a command which would list some such information, but making it omnipresent in the display is a much nicer solution. I finished two games for the seventh Octo Jam, both being rewritten from earlier games, and they can be seen in the after-jam stream: https://invidious.snopyta.org/XIN3hi85IoE Here are their links; the first is Extra Enhanced Enchantment and the second Advanced Asphyxiation: http://verisimilitudes.net/2020-10-27 gopher://verisimilitudes.net/12020-10-27 http://verisimilitudes.net/2020-11-02 gopher://verisimilitudes.net/12020-11-02 Unfortunately, I noticed an error in the tool when writing the second, and one game I didn't bother finishing. Concisely, I was working with a broken name deletion command, which worked in the most common scenario I'd test it in. I only didn't immediately notice because I rarely ever actually delete names. In any case, this shattered my satisfaction with the model. Amusingly, I'm expressing dissatisfaction with my reimplementation in the same post I mention it here. I'd considered a different and higher-level internal representation before, and this flaw only made me realize it as necessary; there should be no opportunity for any mismatches in the system. Rather than work with parallel arrays, as this latest version and its predecessor have, I should be working with an intertwined representation. Rather than having an array of the program, and arrays for names, associations, and types thereof, I should have a single doubly-linked list of high-level instruction objects, where name associations take the place of integers in slots thereof, and different types of data are achieved by simply not having instructions in the list. This will greatly tighten the model, which currently allows for that which the tool will never actually produce, amongst other niceties. I can only wonder how I'll be dissatisfied with it later, but right now it's difficult for me to realize flaws with this better way. I'll be testing this new representation with a new targeting, for the Little Man Computer. I'd prefer to write a longer and more detailed post, but I've taken long enough to write this.

>>22620 >because I found it poor that I'm one of its main posters, Pls keep this thread alive, it's one of the best aspects of computer (sure beats /java[script]?/). It's not my fault that my brain is too small to actually *do* this stuff.

>>22620 I'm with >>22631. I really love reading about this stuff, but lack the skills to take part. Maybe once I'm less busy and get into compiler development I'll take part with some terrible beginner problems...

>>22620 You make me feel hard, I was just scrolling the thread after seeing your post, I noticed I Posted the book linkers and loaders with the SysVAbi in this thread, It was in 2018! Since this time I player a bit with circuit design using Intel tools and a book on verilog but I dont managed to continue because lack of money to buy an FPGA and got more motivated seeing my things working out of a simulator. I hope you keep doing your hardwork and keep posting it here I know some people just come here beucase this kind of content... the main problem is that most of this people are just readers.

Writing ASM is OK to me when you write code to kickstart kernels/bootloaders or use specific instruction sets for critical parts or writing as fast as achievable specific code or you go for specific size limit of final binary code. Outside these areas it's mostly fine to go with C occassionally read deassembled fragments of code that compiler produce to check what kinds of optimization it introduces. At least in cases when you mostly go with flow logic adding little of value to the critical parts or compiler produces retarded code and there is no way of forcing it to produce better code - then just rewrite it. I can see a value of writing few more complex projects in pure asm as educational value. But I doubt I would even go with asm as a main language for writing every single project.

A response to >>23466 in the lisp thread. The AI memo stuff is much more academic than practical although I think some of it could be applied usefully. I've been thinking lately in a more logic oriented perspective when I tackle problems so it was hard to resist suggesting adding in old school AI stuff to your methods. The resulting methodologies are fundamentally different between the two techniques. For instance the AI memo describes ways of working in spite of inconsistent information instead of erroring out or preventing the inconsistencies to begin with. I might have come off in a way where I was trying to compare the constraint stuff to your stuff in terms of functionality. What I was trying to do was give suggestions for more complex tools that you can use in harmony with your current tools. Ideally these more complex tools wouldn't fall into the same traps that complex tools like conventional compilers and assemblers fall into. I have a distaste for assembly in general. There's no reliable rules to anything whatsoever so whenever I try to compose some things I end up with some obscure undocumented error about how some extension to some macro instruction doesn't handle some case. Whereas in languages like lisp there's simple rules for what things do and the complexity comes from how the things are put together, not what things are put together. When I end up with decent source code it's always because the entire implementation of a function is already in my head before I start writing the text out. And there's still things to memorize, but once you're used to the language it's no longer that bad. Especially when the user can look up the use of a function easily. My feelings on the semantics of different machines are more variable. I've been working on tools lately involving x64 so I've been investigating x64 and how it compares to other machines. For me the x64 machine has been a waking nightmare. A bunch of named things that aren't used for what they're named for. Registers are a mix of letters, numbers, and implementation implied names like base pointer and stack pointer. Not that any of the implementation implications are enforced consistently. The RIP register is supposedly a register but it's not allowed to be the result of an addition. There's a weird hack where the RIP can get retrieved into a full fledged register by adding a 32 bit displacement of 0. Then the address can be stored for a function call, or loaded and jumped to for a return. The typical answer to the question of why this is some side hack instead of just having the functionality in RIP as a typical register is to just use CALL and RET. Because why would someone want to store and load the instruction pointer with the instructions that store and load values. One of the many problems with CALL and RET with the process call stack is that CALL and RET use RSP for a stack and don't even check if there's enough space in the stack to make the call or the return. This problem can be worked around by checking beforehand if there's enough space and if there's not then allocating more stack and adjusting RSP before the call but then why bother wrapping custom functionality into call to begin with? The OS situation isn't much better in for example linux the design is to have the call stack be arbitrarily limited and to also have overcommit so that there's no decent way to check for a successful memory allocation. It's like the designers want me to write broken machine code. Going back to x64, there's weird encoding addons. The encoding to specify registers and address modes is split up all over the place with half of the instructions only being able to use half of the registers. There's also weird semantic addons, segments aren't supposed to be important anymore although the segment registers still exist, so when an instruction says it can jump within a segment does that mean it can jump anywhere? If you like pain then look at the pseudo code implementing the semantics of the JMP instruction: https://www.felixcloutier.com/x86/jmp#operation I don't even want to link the pseudo code for the CALL and RET instructions. There's inconsistent features, DIV divides a 128 bit number by a 64 bit number to get a 64 bit division and 64 bit remainder. Presumably this is done for DIV to be the inverse of MUL which multiplies a 64 bit number by a 64 bit number to get a 128 bit number. Although why then does DIV generate an interrupt on erroneous input instead of changing OF and CF like its presumed inverse MUL? There's more oddities, for example a jump if RCX is 0 condition but no jump if RCX is not 0 condition. Not to mention that RCX is the only register that you can jump on 0 for some reason. This is just the core of supposedly simple instructions; the floating point and MMX extensions are their own strange things. A thousand half thrown together feature designs, but no sense of continuity or purpose behind any of it. The more I learn about x64 the more I end up burying documentation and projects involving it deeper into my directory tree as if to hide it in a dark corner of my mind. From what I've seen other smaller machines like CHIP-8 and the Dalvik vm don't do ridiculous stuff like this. CHIP-8 is simple enough that it becomes harder to run into these sorts of design problems. The Dalvik vm does admirably in dealing with interfacing with Java's nonsense semantics and is simpler otherwise. The x64 machine and it's predecessors just seem to be bad all on their own for no apparent reason. No wonder people think that machine code programming is too complicated for them. The x64 machine is one of the most annoying machines I've ever had the displeasure of working with. I can see why people start machine code programming with virtual machines. It's ridiculous when the semantics of CHIP-8 or the dalvik vm can be fit into a couple of webpages, whereas the x64 reference is thousands of pages long and has two different but mostly the same versions from Intel and AMD. In my opinion there's no reasonable way in x64 to just write out all the instructions like your tool does with CHIP-8. You might be able to get a similar tool going for a machine like ARM, although I don't think that doing it for x64 would work very well. It would probably work better than a conventional assembler or binary editor as a tool for building up machine code and looking at what machine code does. For instance the program could prevent users from even entering registers that can't be used by an instruction. Although the manual approach of laying out every instruction byte by byte or opcode by opcode would be difficult when dealing with the convoluted semantics of x64. That is part of the motivation for me suggesting that you integrate symbolic AI techniques to make it so that the programmer can just give the desired result semantics. Then the program can spit out some ridiculous collection of x64 instructions that does the job. So instead of having opaque pseudo instructions in assembly, the program could generate a couple of actual instructions that does what the user wants. Then the user can put those instructions somewhere or modify them and ask if the modified version does what they want. It's weird; I was intending to write more about the purpose of syntax, how writing compilers locks in details by putting in design strategies, and the properties helpful for writing modularized source code and more generally source code that is resistant to additions becoming increasingly complex. Instead I mostly just ended up ranting about x64. I feel a bit stretched out, asking myself how to improve a programming method or tool yields a much more broad, nebulous feeling than just implementing a program that has result X in language Y.

As a late Christmas present, I released the Little Man Computer targeting of my Meta-Machine Code tool, which features a new and high-level internal representation, this being its main purpose. Rather than using parallel arrays, amongst other things allowing failure, it uses a doubly-linked list of tagged data for representing the program. The program is only pressed to its numerical representation upon saving. I could go into more detail, but won't. This is a basic screenshot of it. gopher://verisimilitudes.net/12020-12-26 http://verisimilitudes.net/2020-12-26 >>22631 >>22646 >>22656 Well, I don't mind showing my work to the empty void, but it's certainly pleasant to know there are people actually reading what I'm posting here. >>22677 I loathe the C language. It's nowhere near the true low levels, but so many pretend this isn't so. >I can see a value of writing few more complex projects in pure asm as educational value. But I doubt I would even go with asm as a main language for writing every single project. I'm, of course, primarily doing this for fun. For my development tool, I went from a mistaken low-level approach, to gradually going higher and higher. Most programs shouldn't worry about optimization beyond algorithmic complexity, and should instead seek to be as simple, small, correct, and crystalline as possible. The C language approach is awful in both ways, resulting in neither truly low-level software, nor programs which are small and correct. There's no reason to use it and, had UNIX not formed into the blight on the world it's, few would. >>23523 Excuse that this response isn't as detailed as it should be. >I might have come off in a way where I was trying to compare the constraint stuff to your stuff in terms of functionality. That's what I'd thought, yes. >What I was trying to do was give suggestions for more complex tools that you can use in harmony with your current tools. I've not given much thought to such things. The closest I've gotten is a program which would verify properties of the metadata, such as relationships between names, which the MMC will never be made to do for reasons of simplicity and whatnot. I've still yet to read the paper. >Ideally these more complex tools wouldn't fall into the same traps that complex tools like conventional compilers and assemblers fall into. Perhaps it's best to phrase it as an assembler language is pursuing the mistaken ideal of having the human and machine interface be identical. A compiler should simply generate machine code directly, and the work I've done with mine MMC has informed such designs I want to pursue at some point. Having a compiler generate an assembler language program is simply a muddier and leagues worse pursuit of this same basic principle. I'd like to build a high-level language at some point in my life, which eliminates failure cases similarly to mine MMC does compared to an assembler. I want to entirely remove the notion of compilation as a step, and have everything run at once, as one way of thinking about it. This idea is still very immature, however, and heavily tied with mine ideas regarding machine text, which I expect I may pursue with this next year. >I have a distaste for assembly in general. There's no reliable rules to anything whatsoever so whenever I try to compose some things I end up with some obscure undocumented error about how some extension to some macro instruction doesn't handle some case. My tool would prevent some of this, but it can't necessarily make a fundamentally bad machine code design more tolerable. I suggest using better machine codes, which can be quite fun. I'd be glad to help someone setup my CHIP-8 targeting, as an example. CHIP-8 features some implicit register usage, V0 and VF, and has some oddities, 00CX and 00DX, but is mostly very nice. I've found, in adding a command for automatically producing name associations, that it's much easier to simply load the program and re-enter the few names, then using this, as opposed to writing a real metadata conversion program. >Whereas in languages like lisp there's simple rules for what things do and the complexity comes from how the things are put together, not what things are put together. When I end up with decent source code it's always because the entire implementation of a function is already in my head before I start writing the text out. Writing machine code isn't much different, for me. >A bunch of named things that aren't used for what they're named for. This is one among many reasons to avoid names, yes. My design for this LMC targeting avoids naming even the accumulator, only referencing it implicitly. I'll probably be forced by practicality to use the common names of three of the registers for when I target 6502, however. >This problem can be worked around by checking beforehand if there's enough space and if there's not then allocating more stack and adjusting RSP before the call but then why bother wrapping custom functionality into call to begin with? This seems like a half-abstraction, which is common in poor design. It's obvious that the many billions of transistors in machines should be dedicated to implementing what are effectively high-level languages, but instead these get dedicated to queer instructions and large caches. The current trend is to add increasingly specific instructions that make some machine-learning program's innermost loop one instruction, or to add JavaScript floating point rounding modes. So, not only is the idea that hardware should inherit the most common software barely being followed, it's being followed very poorly wherever it's. This isn't even digging into the foolish cult of RISC. >The OS situation isn't much better in for example linux the design is to have the call stack be arbitrarily limited and to also have overcommit so that there's no decent way to check for a successful memory allocation. This makes perfect sense when one realizes the purpose of UNIX isn't to do any actual work, but just to play the object of worship for a cult. Doing things correctly is seen as a waste of time, I've had C language programmers seriously ask me why anyone would even want to write correct software, and simple interfaces that actually work are spurned in favour of complicated interfaces which don't. >The more I learn about x64 the more I end up burying documentation and projects involving it deeper into my directory tree as if to hide it in a dark corner of my mind. This is why I don't bother with it. >CHIP-8 is simple enough that it becomes harder to run into these sorts of design problems. CHIP-8 is also designed well for its singular purpose, making no attempt to be a general machine. >The x64 machine and it's predecessors just seem to be bad all on their own for no apparent reason. It's bad for the same reason most of computing is bad, that tendency towards accretion. It's much easier to slightly complicate something, rather than build anew; do that for decades, and we get the mess we currently live in. >No wonder people think that machine code programming is too complicated for them. It's also in the interests of charlatans to make programming seem complicated. >In my opinion there's no reasonable way in x64 to just write out all the instructions like your tool does with CHIP-8. I agree. The closest I expect to ever get to that is by targeting the earlier such architectures, and even that's unlikely. >You might be able to get a similar tool going for a machine like ARM, although I don't think that doing it for x64 would work very well. I've only considered targeting MIPS because I own rare such hardware, and even then it's a mess. A nicety of older architectures is consistency, whereas these newer architectures add things without regards to the consequences, supporting so many variants, and there are several ways to handle this, none perfect. >That is part of the motivation for me suggesting that you integrate symbolic AI techniques to make it so that the programmer can just give the desired result semantics. This is just a compiler, which is entirely distinct, and not something I'm particularly interested by with regards to this other work. As with other things in life, I'd much rather simply entirely ignore anything which displeases me, preferably not so much as even mentioning its existence. >It's weird; I was intending to write more about the purpose of syntax, how writing compilers locks in details by putting in design strategies, and the properties helpful for writing modularized source code and more generally source code that is resistant to additions becoming increasingly complex. I'm not certain I understand precisely what's meant by this. >Instead I mostly just ended up ranting about x64. I feel a bit stretched out, asking myself how to improve a programming method or tool yields a much more broad, nebulous feeling than just implementing a program that has result X in language Y. That's the meta-challenge, yes. I feel a similar way. Writing a compiler to machine code is a different manner of meta-machine code programming.

>>23592 >I loathe the C language. It's nowhere near the true low levels, but so many pretend this isn't so. Only people I have heard such statements from are these who never worked with that language, so I don't get why you even care about them. >The C language approach is awful in both ways, resulting in neither truly low-level software, nor programs which are small and correct. Neither of these characteristics were goals of C. It originated as some higher level macro like approach. You are just disappointed that language never had characteristics you care about as it's goals. Yet there are small and correct programs written in C.

>>23594 >Only people I have heard such statements from are these who never worked with that language, so I don't get why you even care about them. I'm simply responding to someone who mentioned it. It's not the first time I've had a discussion about machine code, only for a C language programmer to step in, remark on how the C language is generally good enough, and question why people would even bother programming so. I want to program optimized machine code, taking advantage of its homoiconic qualities and other such things for ever greater programs. Were I not concerned with this, for its fun, I'd be writing solely in very high-level languages instead. It occurs to me I've not shared my favourite passage from a book, Alan Turing's Electronic Brain, so I'll do so now. This is the level of machine code programming my tool has been designed to enable: >Optimum coding-good or bad? It led to very fast routines but we could overdo it! I recall that when a built-in divider was available on DEUCE, I explored the usual iterative method for finding square roots to replace our digit-by-digit method learned at school. I found that for a floating point number x in the range 1/2 - 2, a starting guess of a + x/2 gave full accuracy through the range with, if I recall correctly, three iterations. The value for a was around 0.48. By chance, I spotted an instruction which when converted to decimal was about this size, so I used it to save a store. Some time later, a puzzled user had considerable difficulty in understanding my inadequately documented routine. >Neither of these characteristics were goals of C. It originated as some higher level macro like approach. The true derivation chain is Algol to CPL to BCPL to B to C. >You are just disappointed that language never had characteristics you care about as it's goals. I'm not disappointed. >Yet there are small and correct programs written in C. Sure. Now, I really don't want to discuss this more than I must, so I'll perhaps choose to no longer respond to posts about this topic for the immediate future.

>>23596 >The true derivation chain is Algol to CPL to BCPL to B to C. This chain does not contradict "macro with extra beef" approach I wrote about. That approach screams loudly in basic concepts of C. They just happen to base language on previously existing languages beside that.

>>23596 >I'm simply responding to someone who mentioned it. It's not the first time I've had a discussion about machine code, only for a C language programmer to step in, remark on how the C language is generally good enough, and question why people would even bother programming so Good enough for what? As general purpose it is good enough. It has been proven in practice numerous times in numerous areas. As special cases low level manipulation? No, it's where asm is used. As a fast, nobrainneeded prototyping language? Not good here. As a language You Get What You Write? Mostly nope - as most compilers are into sometimes crazy "optimization" tricks.

>>23596 To go as far as to 'loathe' a language because someone said something that was neither true nor called for on some burmese glassblowing forum is, well, kinda stupid.

I'm wondering if anyone has any suggested resources regarding x86-16, and early IBM PC compatibles. I'm interested in the possibility of writing real-mode software due to the simpler I/O, instruction set, and access to existing hardware. I'm unfortunately very busy so this would simply be put on my stack. I'm certainly in no rush to find these resources, so don't go out of your way to locate them, but I would still love to have them for the future.

Does anyone know why the ENIAC used base ten even though Mauchly, and Eckert were intimately aware of the Atanasoff–Berry Computer which used base two? I've read that they considered it would require too many tubes, (450 instead of 280 for a simplified accumulator) because of the complexity introduced by the circuitry for transmitting and receiving from units. What is the source of the complexity, the voltage differences? Why not just have buses of width thirty to transmit the whole binary word equivalent at once even?

>>25114 A related question, why would you want both signed magnitude and radix complement representations, especially if you're concerned about reducing the number of tubes? My current interpretation is that function units typically work on the entire word without processing the tens compliment, presumably because this was needed for some target work of the machine. If the output of function units needed to be stored in an accumulator, two accumulators would need to be chained together to allow for storage in tens complement of a ten digit signed quantity (perhaps this is why there are twenty rather than ten accumulators). One might then wonder if the function units are presumably used frequently why not just have the signed interpretation with comprehension in the accumulators, even if this meant half the number of accumulators it would often mean simpler wiring. I suspect this might be due to the inefficient punch-card based storage for intermediate values. The number of intermediate values on this system could have significant performance implications, and since it was exactly this that plagued the ABC, perhaps Mauchly and Echert were particularly anxious about this issue? (In general it's interesting how significant IO was in the early days (at least in the US), it's why the ABC was destroyed, why the Mark I was more useful than the ENIAC, why the IBM crushed UNIVACs, why bit-parallel beat bit-serial (even though now having many bit-serial machines seem better) etc.) Does this track?

What are some good resources on writing your own assembler?

This is pretty interesting if you like CPU design and CPU implementation details: https://www.agner.org/optimize/microarchitecture.pdf >>26202 What do you mean exactly? For the most basic case you just need to map the mnemonic to the binary encoding from the CPU spec. Having directives for data is going to be specific to the executable format, so read the ELF spec or equivalent and figure out how sections are laid out, how the headers are constructed, etc.

>>26202 I remember reading this when I was younger. Don't know if it's good because I actually haven't tried implementing anything, but maybe it's useful.

>>26202 I'm also interested in resources on developing an assembler, particularly for x64 since it's the only asm I'm greatly familiar with and the one I write the most. I did find this https://github.com/skx/assembler in golang, though it uses int instead of syscall which isn't great.

>>23592 I've been focussing on my language modelling system, and learning Latin, so I've done very little machine code work with this year, still using the version of my tool from 2020-07-07. Regardless, I wrote but one game for this year's Octo Jam, although I'm not certain if it were included in any video or not; the lack of stimulus will help, however, as the Octo Jam has had me postpone work before, and so lacking what little sensation participating gave me will help me work on machine code in months other than October. The game is a very basic nonogram puzzle game: http://verisimilitudes.net/2021-11-11 I intend to write later versions of the game with a better design and more puzzles; in particular, my next design of the entity count collecting system, named decode here, will use a table approach with a simple composition rule to avoid needing two hundred and fifty-six entries. I'm particularly pleased with the compare routine, which is constant-time and so prevents the player from being able to time the puzzle comparison to leak secrets. In most other respects, this is the laziest game I've written.

>>28667 Assembler can be as basic as just translating mnemonics and operands into machine code. But this would mostly be OK for some simple embedded stuff with simple processors. The more complicated assembly language and more complicated error detection you want - the more work it requires. In general case reading Dragon Book and manual of CPU you are targeting should plus familiarity with flex/lex/bison/yacc would be sufficient for at least starting the project without too much hassle.

>>28822 I was wrong, they simply took their time releasing the video: https://invidious.snopyta.org/watch?v=52AdEMjciDY They start playing mine at 01:28:09. It's a shame only the first puzzle was solved, due to it being trivial, since the second puzzle was a swastika I would've liked to see on-stream. I need to start writing better games, there were a lot of interesting games this year at a glance, but I so prefer the simple and pure gameplay provided by an entropy source; this was the first game I wrote that doesn't really match that mold, though, relying on handbuilt puzzles.

I don't believe I've done any machine code programming at all with this year, although I do mentally mull over designs in my spare time. It's more than a little sad that I'm keeping this thread alive. >>22620 This game suffered because the program has two main parts, but I didn't divide it well; I should've saved all registers between parts to have more breathing room. I may rewrite it during this year, and also add an enemy; I've already figured out how to add a large enemy to fit the cadence of the maze generation and scrolling machinery, and the grid of the maze ensures it could put up a challenge with minimal intelligence behind it. I have an idea: I'll try to get a little program finished by the end of the month which also exhibits a style of programming I've grown to greatly value. A high-level language can and has expressed this little program, but I'm not satisfied with it; at the machine code level, however, I can set each little bit exactly how I please, and this total control can be not only satisfying, but also can show off the style in ways a higher-level language wouldn't. It will be a complete and correct little program.

I do a lot of low-level programming for CPU and GPU stuff. Hell I even work on runtime JIT recompilers for old emulators and stuff. It's fun. Though I am getting a little tired of x86 in particular. AArch64 has been fun though. NEON has been an absolute dream compared to X86 SIMD. Have a lot of hope for RISCV once there is a notable device work speaking of that implements RISCV that doesn't have a kernel and user-space that isn't at the mercy of a bunch of programmer's free time. Until then, x86. Latest thing I want to play with is writing an abstraction of some sort around Intel's AMX instruction set for matrix operations.

>>32822 I should stop giving estimations of when I'll get around to finishing certain things. Here's that first little program: http://verisimilitudes.net/2022-10-31 I only augmented a previous game submission as the only other thing I finished, due to mismanaged time, and I've yet to document it. Here's that video of the game jam, in any case: https://invidious.snopyta.org/watch?v=F56lJGeqzg0 I should target the 6502 at some point within the next two years. That may prove to be more interesting in key ways, and I'll be able to move on from CHIP-8 to other types of games.

Well, with another October comes another Octo Jam: http://octojam.com I've had plenty of ideas over the years I've yet to be able to use. One idea I started and never finished was a CHIP-8 implementation of Kunekunetchyo, described here: http://blog.beforemario.com/2014/04/gunpei-yokois-final-two-games.html Here's the description from the link: >The game basics for all these snake games are the same: control a moving snake around the play area, without it touching either the walls or its own tail. You score extra points by eating food pellets, which also add to the length of the snake, making it increasingly more difficult to maneuver. >In Kunekunetchyo, a nice little extra challenge is included. The food pellets do not remain stationary on the play area, but move horizontally or vertically from one side to the other. Not only does this make it harder to judge where to steer the snake to catch the pellets, but you have to eat the pellets before they cross the play area; when one of these pellets reaches the other side, it is also game over. I've had the basic design finished for a while in my mind. The graphics I've already finished are specifically designed to well use the sprite collision provided by CHIP-8. Anyway, it's a shame that I'm the only one using this thread.

I feel like writing things directly in assembly would be way more common if assemblers got with the program with structured programming. A lot of the challenge in working with assembly, at least for me, comes from having to chase labels around the giant codebases it necessitates.

>>38364 And trying to double-check quirky register allocations, especially in assembly dialects with implicit registers or register ranges. I've long thought a Clike syntax with: -> opt-in automatic (sub!)register allocation for individual variables -> opt-out (sub!)register allocation checking -> programmer-controllable calling & return conventions -> all optimizations that would affect program order (branch reordering, notably) being opt-in ...would be interesting.

Hello, not sure if this is the right place to ask, but it seems like the most appropriate thread for my questions. Lately I've been trying to implement an x64 assembler backend in Common Lisp, I've been lucky to find [this project](https://github.com/rayiner/amd64-asm) which is a great basis to start with, but lacks some features I intend to implement on my own. So: What are far jumps good for? When do we need them? Does it make any sense to implement them, and, if yes, what would be a good way to go about it? To clarify, **I only really care about long mode and assembling relocatable objects. The assembler, once paired with an appropriate frontend, should work as a drop-in replacement for something like NASM.**

>>40982 Pure assembler? Or does it handle linking also? Far jumps are mainly just for cases where you can't fit the jump displacement into a near jump. Most common causes of this are linker sections placed very far from each other, or large programs, or places where you want to be able to put an arbitrary target address with no guarantee it is close. There are a couple of ways to go about jump relaxation (as the process of figuring out 'do I need a far jump' is called). You could: a) just use far jumps everywhere. Simple but inefficient. b) have an explicit pragma / compile flag / etc for near jumps. c) Initially assemble everything to near jumps, and if things don't fit insert a trampoline that just does a far jump to the actual destination, and near-jump there. This can cascade into requiring more trampolines if you're unlucky. d) Initially assemble everything to near jumps, and if things don't fit replace some jump(s) with far jumps and try again. This can cascade into requiring more far jumps if you're unlucky. If you're saying 'wait, that sounds like assembling and linking are commingled'... there's a surprising amount of overlap, and ways to make the linker cry and/or fall over.