>eh this is starting to sound interesting.
I appreciate it.
>i'm hoping to have some sort of 1337 optimizations by taking machine code into consideration, like having code jump into the middle of other instructions and such (assuming that's even useful on a modern superscalar processor)
I wouldn't know about speed, but it can be more memory efficient, certainly. I've dealt with a lax range model in my tool, where you can jump to the middle of an instruction and it will disassemble from there, but there are also some oddities with this model I won't go into much detail on. I'm expecting to use a much more structured range model in the simpler reimplementation, while still allowing one to split instructions into pieces and then re-piece them offset if wanted.
In any case, there's still no replacement for knowing the machine code well enough to know that you lack a non-negotiable part of an instruction and can't change the code to accommodate this and so must look elsewhere. It seems to be a common thread that it's easier to use code as data than data as code or offset code as code, but all of these are still so very interesting.
>What is the reason for re-writing it from Common Lisp to Ada? Just as an exercise for you, or is there a practical reason?
It's both. I'm learning Ada and this will be a good first project. I'm also wanting to make the program very resilient in many ways and Ada has facilities for this that standard Common Lisp lacks.
Common Lisp has STORAGE-CONDITION, but you can't really handle it in a perfectly portable way. The MMC will allocate in two main instances: when instating a file and with regards to the undo and redo system; there is another case where names can be dynamically allocated to avoid storing thousands of them and wasting memory. I'd like the MMC to be resilient against memory exhaustion errors. I'd also like to be able to ask the terminal its size, rather than relying on behaviour I use in my ACUTE-TERMINAL-CONTROL Common Lisp library for determining the dimensions. Ada has facilities that will allow it to use ioctl() and establish signal handlers and other such things, which I didn't bother doing in Common Lisp.
So, the Ada reimplementation will use less memory, be resilient against memory exhaustion, respond to POSIX signals as I see appropriate, among other things I wouldn't do in Common Lisp, such as look at the program arguments. This isn't to write that I care for POSIX or other such things, merely that I will begrudgingly support them.
Further, Ada will likely be easier to distribute. I've been working on a Common Lisp convention for installing libraries and whatnot, but it's not progressed much yet. The program is currently a sh script that searches for a Common Lisp implementation and loads it appropriately.
You can see what the program currently is here: http://verisimilitudes.net/mmc-chip8
>I don't quite see the point of this program, but I might be just a brainlet in that regard.
You wouldn't be the first to not see the point. The point is that I want a nice machine code development tool and I willed it into existence. It's fun to realize a novel program. I've used my tool now and I certainly don't want to write machine code in any other way.
Also see >>1000280 for more of my thoughts on why machine code development is a good place to experiment.
>I like. I wish you well OP.
I appreciate it.
>It's good to see an actual /tech/ thread with good content.
I'll freely admit I don't post on 8chan often. I usually use a much smaller venue, but wanted to branch out so other people would learn of my tool. I tried proselytizing my tool on a few different places, but no one had anything to tell me. I'm glad to have received such a nice discussion.
I'm so accustomed to anonymous imageboards and it seems like I'll stay this way, for the most part.