Meta-Machine Code

I would like to show off a tool I've created; the included image is an example of the tool with a program I've written loaded; the main page for this tool can be found here:
verisimilitudes.net/2017-07-07

The page for the only current version of the tool is here; note it is an immature page in comparison:
verisimilitudes.net/2018-08-08

This is an interactive machine code development environment I've created. The basic idea is each key of the keyboard, decided by position rather than value, is bound to a routine which asks questions until an action can be decided upon. An example is pressing a key for a routine that merely needs two registers in order to complete; you're permitted to enter a register number, the tool won't allow invalid such numbers to be entered at all, it asks again in the same way, and it then writes the finished instruction to the current location; if a name referring to a number was used, that name will likely be displayed instead of the numerical value, varying, and any changes to the name will update the instruction as well.

I wrote this tool in Common Lisp purely because Common Lisp has the necessary primitives. The program is decidedly non-Lispy. I'm planning to write a simpler reimplementation in Ada by the year's end and expect this will be the version that is distributed to package managers and whatnot. Some simple figuring has shown to me that the memory usage for this program, sans any undo and redo mechanism, should be well within an eighth of a megabyte in the general case and below a quarter in all cases.

The tool was borne of my dislike for assemblers. Answers are saved by similar routines and so you can very easily press keys until you find the one you need; you can't touch and feel your way around an assembler. Aside from this, there are also special routines, primarily located on the home row, which control movement, insertion, deletion, jumping around the program space, creating and deleting names, and other necessities.

In contrast to a one or two pass assembler, this is a no-pass tool, as everything must at all times be in a valid state. You can't use a name before it's created; updating a name works modulo its usage size, preventing errors from surpassing limits; and deleting a name merely removes the association, preventing further updates upon changes, among other such measures.

This is a reasonable description of the tool. Currently, only I can use it, because it's not in a friendly state for installation and I only have a correct Dvorak mapping created. I'm also still refining it and removing bugs I've added during this refining. The entire system, including the three libraries I wrote for it, is less than two and a half thousand lines of code.

I've been trying to show this tool to a wider audience, but I've not found much of one yet. Feel free to tell me what you think and ask any questions concerning the tool.

Attached: mmc-fizzbuzz-in-cool-retro-term.png (1280x800, 584.05K)

Other urls found in this thread:

sourceforge.net/projects/hlav1/
plantation-productions.com/Webster/
verisimilitudes.net/mmc-chip8
verisimilitudes.net/2018-08-18
verisimilitudes.net/2018-08-28
verisimilitudes.net/2018-11-01
verisimilitudes.net/2018-12-12
verisimilitudes.net/2019-03-03
emojicode.org/
verisimilitudes.net/2019-06-23
twitter.com/NSFWRedditImage

Here is another screenshot of this program in a different terminal emulator. As I added functionality to my terminal library, I found myself adding more and more to the display, such as color. I find it quite nice.

Attached: mmc-russian-roulette-in-gnome-terminal.png (1280x800, 180.72K)

It looks really interesting, but... What's the purpose?

The purpose of the tool is to write machine code. The only current targeting targets CHIP-8, but I'm planning for MIPS and other architectures later.

I don't believe an assembler is the best way to write machine code and I also don't see many tools targeted at machine code.

It sounds a little bit like HLA
sourceforge.net/projects/hlav1/
plantation-productions.com/Webster/

x86 when?

HLA is a high level language placed over assembler language. It's my understanding HLA has its own preferred way to arrange some data types and whatnot. I'd rather use a normal assembler.

Two of the key aspects of my tool are interactivity and, since the tool displays instructions independent of inputting them, detailed descriptions of instructions. There's a single CHIP-8 assembler I'm aware of, which I roughly compare my tool to in the article, as a good example, I think.


Well, x86 is an architecture that doesn't even work well with an assembler. I've considered supporting the old x86, but I refuse to support x86_64, as it wouldn't work well at all with this model.

My tool works best when the number of instructions is manageable and a good number is around one hundred or so; CHIP-8 has less than fifty and fits on a single keyboard without any squeezing.

If I did want to support x86_64, it would require much more work than I'm willing to put in for it to see if it would at all be usable.

from reading a few sentences on this site it looks like it might be written by a markoff chain, but ill read more later

This might be an interesting way to program microcontrollers, though I rarely do that anymore. Regardless, I applaud your efforts.

Indeed, I'd prefer some kind of ARM implementation before any kind of x86.

hipsters deserve to be crusified

pure autism or why?

I appreciate your kind words.


ARM is perhaps what I intend to target after MIPS. ARM has many variations and extensions and whatnot, but I'll probably find a suitable solution.

Tying in to my next paragraphs, I've considered how to handle the peculiarities of shifted ARM integers in my tool. An assembler will simply fail if you enter invalid such constants. My MMC targeted at ARM will support these in the integer collection routine and you will not be able to enter an invalid such integer.


I explain this in the main article, but I can repeat the finer points. An assembler has an assembler language, which obscures what machine code actually is. An assembler language hides instructions behind mnemonics, introduces pseudo-operations that have no relation to the machine, and makes self-modifying machine code more difficult.

An assembler is not interactive and provides no help. My tool not only ensures you can't answer questions incorrectly, such as by providing values out of bounds, but you don't need to remember much about particular instructions at all, as the tool gives descriptions. You can set a beginner in front of my tool and step them through it much more easily than you could an assembler and I didn't even originally set out to make something good for beginners.

As an aside, I'm rather pleased that I was able to create something novel. I hold the opinion that abandoned fields are fertile ground for novel research. If I wanted to create a novel functional programming language, I would've already had my come and go before an established language consumed my work. However, I seem to be the only person who's experimenting with creating a nice environment for machine code programming. So many people think assemblers are natural or the only way. They're not.

any legit use case for this?
1:1 relationship is not hiding.
nobody forces you to use them.

In a TL;DR version - an assembler that shows opcodes and the bit patterns in memory?
Good!
What I dislike about general assembly is, it's too high a level language compared to how things used to be.

Yes. The general homoiconic nature of machine code is valuable. It's typically easy to use code as data than vice versa, however.
I mean rather than thinking about the actual instruction, you must recall whatever the mnemonic is. My tool binds them to keys without names.
They're generally necessary in some way. I've seen newcomers confused by some of them before and, as assemblers are so old, some of their qualities are apparently taken for granted and hard for someone to learn of unless they already know what they're doing.

I don't need pseudo-operations, but sometimes the underlying mechanism, such as specifying precise alignment, is valuable. I've already thought of separate tools that could be used with this one for such.


It is because my tool isn't an assembler that it can do these things. Think of it as machine-assisted creation of machine code. You're not using a text editor; you're using a tool that is designed with an understanding of what you're doing. You don't need to recall any names or assembler language syntax, because it isn't there. Also, with the way the tool is designed, it can be used as an examiner for already written programs without any real changes to how it's used, so it can be thought of as multiple tools in one.
That's one way to think about it, I suppose. The label system, which are just names bound to addresses, did come about because I didn't want something that was weaker than an assembler in any way. Making it convenient to shuffle code around was necessary.

This seems to actually be good software, I am looking foward for your final implementation of this tool.
So, if I understood what you wrote, will it be possible for the user to set up the tool to write in any target instruction set as a feature?
Also, assuming one commit to memorize hex values of an instruction set, do such person can benefit from your tool in any way?

I appreciate your kind words. I'm not quite finished learning Ada, but I expect to finish the book I'm reading, Programming in Ada 2012, and perhaps the simpler reimplementation in Ada by the end of this year.

However, I'm considering that I may get it out sooner if I simply cleanly reimplement it in fresh Common Lisp and distribute that, at least for now.

I'll explain. I'm planning to have a distinct release for each targeted instruction set. So, the CHIP-8 targeting will be one tool and the MIPS targeting will be another and so on.

I had the idea of making each targeting customizable, but wanted to avoid an arbitrary customization mechanism. The only thing that wasn't arbitrary would be customizing the tool itself in machine code. I went on a great detour with a Meta-CHIP-8 I created and wrote the current implementation of the tool with. As an aside, I've tested this program under GNU CLISP and even under multiple levels of interpretation the tool behaved instantaneously, so I'm confident a very well optimized implementation will be more than fast enough.

I'm still holding on to this idea of a self-hosted MMC that loads machine code corresponding to the individual routines for operation, but I see this as being secondary to getting the tool working in an uncustomizable form, such as an Ada or Common Lisp implementation. Also, I found customization rather unnecessary for the CHIP-8 targeting, actually.

I've also learned that customizing a tool in machine code isn't a great experience, but I've been experimenting with a suitable simple compiler of sorts that would allow you to declaratively specify routines and use them from within the tool. That is, I could expose routines to create new routines and bind them and whatnot. These last three paragraphs have been a tangent, somewhat, but they give an idea of my future goals with this.

I believe so. I consider this tool to be IA (Intelligence Amplification); the tool can help someone who isn't intimately familiar with the instruction set and would lessen the burden for someone who is. Now, by implementing this tool, I become intimately familiar with the instruction set being targeted, but I already have a few people new to machine code I intend to step through and teach with the tool, so I'll be able to see how a newcomer approaches it soon enough.

Provide at least 1 example where/why is it valuable.

It's not a problem if you aren't a brainlet (and if you are then you are you doing machine level coding in the first place)

What even is the point of this?

A program can be smaller by loading code as data rather than repeating data. Now, unfortunately, CHIP-8 has a bit of a clunky memory access mechanism, so the best example for CHIP-8 is perhaps using code as sprites. You're more likely to see a sprite you could use if you're looking at the code as a sprite, which is its binary representation.

I'll figure that should've been (and if you are then why are you doing machine level coding in the first place).
I disagree. Smart people use good tools and I don't want a tool that offers little and gets in my way. See my answer to this next post.


I wanted this tool to exist, so I'm willing, or rather have willed, it into existence. This is how I want to write machine code. I quite like it, so far.

MissingNo flashbacks

eh this is starting to sound interesting. i always liked (re)programming in the likes of ollydbg, or reading in IDA, and they have features that even high level languages lack. i'm currently writing a lot of x86 assembly, and have been wanting some stuff to help me think about the machine code more often. right now all i've done is avoided REX prefixes to make my code smaller and avoided using 64-bit immediate values as that seems to slow the code down a lot in my benchmarks. 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)

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?

I don't quite see the point of this program, but I might be just a brainlet in that regard.

I like. I wish you well OP.
It's good to see an actual Zig Forums thread with good content.

I appreciate it.
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.


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: verisimilitudes.net/mmc-chip8

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 for more of my thoughts on why machine code development is a good place to experiment.


I appreciate it.
I'll freely admit I don't post on Zig Forums 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.

Attached: op is full of shit.png (904x609, 20.75K)

Just today I finished updating some articles I've written relating to this tool:
verisimilitudes.net/2018-08-18
verisimilitudes.net/2018-08-28
verisimilitudes.net/2018-11-01

I would've preferred to have purely text and have the reader step along in my tool, but that's unreasonable at the moment, so what I do is I take the output of my tool and write around it. I have ASCII versions of the articles with ECMA-48 color codes and the versions that I've directly linked to, which are the ASCII versions translated to HTML.

These are the only three I've done so far, but there's four more I have to document before I've exhausted all of those in VIPER magazine. Then there's still documenting my own programs, of course.

I was originally vehemently opposed to making the output of the tool able to be taken and used statically in this fashion, but lately I've been considering a mode that would make the tool itself perform a batch process of outputting its display in perhaps TeX or something or another.

Thanks for the updates I continue to check back here every so often.

I've now finished documenting another CHIP-8 game; the article may be found here:
verisimilitudes.net/2018-12-12

I no longer believe I'll necessarily have any work on the Ada reimplementation finished before the end of this year, but I do expect to finish most of the book, having already read more than half, and so be reasonably competent to do so at the year's beginning.

I did spend a day in which I'd try to reimplement it simpler in Common Lisp and see if I could get that done in a day and if so use that for a tad, but I didn't.

I don't have another game documented yet, but I still have some progress I can report on.

I'm soon to read the nineteenth chapter of my Ada book, covering generics; once I finish this, I'll feel comfortable knowing the language well enough to write some libraries I'll need that won't need dynamic allocation and other such things.

What I'll first be doing is implementing similar libraries for terminal control I've written in Common Lisp in Ada. I'll then be using these to write the main tool.

So, that's what I've been up to lately. I may be using my current prototypical implementation to write another game or I may be waiting for myself to finish this simpler reimplementation; that comes to how fast I progress on the reimplementation and the playing of games others wrote.

I'm sorry user, this subject is too complex for you.

Go back to /r/linux

As another update, I intend to have an ECMA_48 Ada package finished by 2018-01-31. However, I believe I'll be writing the main program ahead of time and adapting it to use the libraries once those are finished, so I progress more quickly.

I also believe I'll be hunting down the last few queer bugs in my current implementation, related to inserting and deleting, and then use it to implement my first real game in it, which I'll be limiting to 1K and trying to fit as many nice variations of tennis in.

As it turns out, trying to take the same approach I took in Common Lisp with heavy metaprogramming was a poor idea. I'll just be implementing the abstraction over ECMA-48, implementing only those procedures I actually need.

I've made some progress with this, working on the program in largely the same order I did the Common Lisp implementation, working on fairly independent parts based on what's interesting and easy. I'm not accustomed to using a language without knowing all of it, but I'm adjusting well enough to Ada.

I've yet to do this, due to sloth, I suppose. I believe I'll work to have another documenting available on 2019-02-22; I like such repetitive dates for my articles.

I suppose I'll bump this thread if and when I have more finished or of note to share, but will otherwise let the thread die if not, since I've been the sole bumper the last few times.

I think it's interesting. Don't stop on my account.

Looks really cool, OP. I've done experiments with block characters representing binary.

fucking rad OP
don't got time to check deep atm, but saved a pdf grab as "interactive machine code programming autism.pdf"
good stuff

I've finished documenting another game from VIPER magazine, this one being a nim game:
verisimilitudes.net/2019-03-03

I also uncovered an odd bug in my program while inspecting another game in the course of writing this. For some reason, the 0XXX routine would improperly report any address under fifteen as zero. This is the manner of bug of which the mere existence is a warning sign. The Meta-CHIP-8 I wrote that implements this routine is not only inflexible, but also rather inscrutable, since I no longer want to invest the time to correct it. I'm glad I'm making progress in my reimplementation, so I can do away with this first iteration.

HAPAS ARE SUPERIOR TO WHITES

The first point that you need to note is that Whites were historically a great civilization. I don't deny that, after all, they controlled over 3/4 of the world at some point.
The second point that you need to note is that Asians are autistic bug-people with no empathy. No empathy = less societal progress since they let people die randomly despite their worth to society.
The third point that you need to acknowledge is that white people have lost any and all traits which made them a powerful and superior race. You NEET-Sock larpers take achievements from the last great men in NS Germany and attempt to make them your own. You haven't done shit. White people are 100% jew controlled, and this isn't because the jew is particularly powerful. This is because white people are emotionally weak. Why? Whites have been undergoing severe devolution over the past 100 years. The two jew-induced world wars killed off entire generations of strong, brave white men, and this has KILLED THE WHITE RACE. You pathetic Nig-Sock larpers need to understand this. There's no coming back from this.
White people are weak and pathetic. They have lost 100% of what made them great through a jewish dysgenics program, and while this is unfortunate, it is also irreversible. So forget about it.
Hapas, more specifically White/Asian hapas, are the new ubermensch, so to speak. We are superior to both whites and asians since the properties of both races are polar opposites, yet meet in the middle to form an optimal combination. Whites are too cucked and have too much empathy, so much so that they feel excessive empathy to subhuman races like niggers, jews and arabs.
On the opposite side of the scale, asians have too little empathy, being perfectly content to watch their fellow countrymen run over by trucks, poisoned by fake food products, gassed by the very air in their cities, and executed by their own government for petty reasons.
These two qualities are, as I mentioned, polar opposites, and neither are beneficial to the well-being of society. Hapas possess something in the middle of these polar opposites. We are much more racist than white people. And at the same time, we have empathy towards each other. Our women are far less slutty than white roasties, contrary to /poo/ disinformation - white men prefer white or asian women, not hapas. I know this not only due to theoretical knowledge but due to actual life experience talking to others of my own kind. We only require the tiniest push to fully support anti-nigger, anti-shitskin and anti-kike ideology, whereas whites never go all the way. Whites can only become magakikes, or anti-illegal-immigrants at the ABSOLUTE best.
Hapas are small in number at the moment but with further degeneration of the white race, racemixing between whites and asians will become more frequent. Hapas will rise from the ashes of the white race and inherit the world.
It is often stated by Nig-Socks that racemixing is evil and bad because "the product of racemixing contains neither of the desirable qualities of the two parent races". This may be true under ideal conditions, but Whites and Asians don't have any desirable qualities by themselves. The races have been degenerated by decades of communist (i.e. jewish) dysgenics (in the case of asians) or decades of war-induced jewish dysgenics (in the case of whites). As such, the ordinary Zig Forums theory no longer applies. Neither of the parent races, whites or asians, actually are suited to their environment. They also happen to have polar opposite qualities, which conflict with the goal of societal stability. This is why hapas are not inferior, but superior to both races.
Note that what I said only applies to White/Asian hapas. Any mixtures containing shitskin or nigger genetics is just as bad as the shitskin or nigger genetics would be by themselves, since shitskins and niggers were never a part of great civilization.

for this year's april fools, please make an emoji display option for meta-machine code like how emojicode.org/ does it

I don't put April Fools' jokes on my website. I bump this thread, but I've taken a break from IRC and whatnot and intend to for a bit. I'm already more productive and well-off, not wasting my time with it. I've known this for a long while, but I still use it so often.

What I did today was update my CL-ECMA-48 and ACUTE-TERMINAL-CONTROL a tad, making minor improvements. I'll fiddle more with the Common Lisp or Ada 2012 tomorrow, perhaps. I can see myself having the main loop of the Ada finished soon, now that I'm not so callously wasting my time.

I also have a Gopher server now, so I may simply work more on that. I don't care for the networking libraries available, so I need to work on my own before I write something good.

Anyway, I'd really enjoy seeing what those of you who told me you were going to take a look and come back later have to think of it. I write to be particular, but anyone here, really.

I made some more improvements to my horrible current implementation, but linking screenshot images over and over would get old quickly.

super optimized machine code is already being used like in consoles to accelerate game engines
but this could be something like that in open source...

As an update, I've finished the display and creation functions. So, what remains for Ada is writing the more base routines. That which implements much of the personality of the tool is rather finished now.

I believe I'll be using the current implementation of the tool to write another game soon. I'll discuss more later.

That brings me to another topic. I'm considering participating in the finger protocol and writing about my progress with it. I intend to also ask elsewhere, but would any of you actually be interested in reading development logs for something such as this?

It's my understanding some people are interested in reading people's development logs. My current format leaves many of the details behind, in my far less numerous articles.

Good, your hate has made you powerful. Now, fulfill your destiny.


I'd rather read those than another browser battle thread, but might be best to leave a link here to the detail somewhere on your website and only periodically summarize here, so anons don't complain about blog posting.

HAPAS ARE SUPERIOR TO WHITES

HAPAS ARE SUPERIOR TO WHITES

HAPAS ARE SUPERIOR TO WHITES

HAPAS ARE SUPERIOR TO WHITES

HAPAS ARE SUPERIOR TO WHITES

HAPAS ARE SUPERIOR TO WHITES

HAPAS ARE SUPERIOR TO WHITES

HAPAS ARE SUPERIOR TO WHITES

why not go for RISC then

HAPAS ARE SUPERIOR TO WHITES

HAPAS ARE SUPERIOR TO WHITES

MIPS is the next intended target, purely because I own a Lemote Yeeloong.

I smell rats.

Whatcha sliding Chaim?

Looks like some Soros-funded controlled opposition to me.

Masons, Masons everywhere...

Masons, Masons everywhere...

This new captcha is ridiculous, not that having a captcha at all wasn't already ridiculous.

Anyway, I only bump to let you know I now have a Finger server of sorts under my domain. I repurposed my Gopher server, effectively.

You can access it with, say, lynx in this way:
lynx finger://[email protected]

I'll also let you know I'm going to have an article detailing a comments system on 2019-05-30. I've been disappointed and disgusted with my attempts to collect any thoughts on my articles and whatnot anywhere, sans imageboards. As an aside, upvoting systems seem to teach people that they shouldn't give any thoughts whatsoever, when they can simply give an upvote instead.

In any case, perhaps periodically discussing myself publicly with this Finger will help me work more effectively or organize my efforts better. I've done very little work on my MMC since getting it in a working state since 2018-08-08, but I still have the rest of this year to work on it before I miss my deadline. It's still mesmerizing to look at it and know I've breathed life into my idea, even if it currently falls short.

That's all.

Dude I didn't expect OP to be a no-fun hard-ass who take everything seriously, can't we just have easter eggs that makes the software a little bit more "cheerful"?

What got you started in this? Where you creating vydia for a graphing calculator? This is a little 2600 for me. The first machine I wrote assembly for had a 4th gen Core i7. Low level coding takes a lot of persistence. Great project. Tier 1 autism.


Why not do X86 with just the short instruction set. Most X86 programs can be written with just 13 instructions.

they are probably behind closed doors getting paid for their work also enjoy certain privileges.?.

forgot to mention your work looks really intrigueing i hope you achieve your goals , godspeed user

I have a single Easter egg planned.


In my 2017-07-07 article, I explain how I was waiting in a car in parking lot and, to pass the time, started mulling over a novel instruction set. I realized this instruction set wouldn't be suited to assemblers even moreso than Intel and so began considering an alternative way of writing it. That machine code is a failure in the general case, I believe, but the tangential idea of a development tool for machine code has lived on and become this tool.

I may end up targeting x86 in some way, at some point, but I don't ever see myself targeting x86_64.


Perhaps. Research that isn't public doesn't mean much. I've had the opportunity to show this to some others who have also seen nothing similar.


I appreciate the kind words.

I've a new documenting; it's also available over Gopher, of course:
verisimilitudes.net/2019-06-23

For those of you who have been using my Finger service, you'll know I don't update anywhere near every day, but I do have some reasonably interesting tidbits.

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, 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.

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.

Okay I take that back at least it would be fun... somewhat