/tech/ - Technology★

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

>>999952

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

https://sourceforge.net/projects/hlav1/

http://www.plantation-productions.com/Webster/

>>999959

x86 when?

>>999991

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.

>>999994

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

>>999945 (OP)

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

>>1000202

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

>cool retro term

hipsters deserve to be crusified

>>999959

>I don't believe an assembler is the best way to write machine code

pure autism or why?

>>1000202

>Regardless, I applaud your efforts.

I appreciate your kind words.

>>1000238

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.

>>1000274

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.

>>1000280

>self-modifying machine code more difficult

any legit use case for this?

>An assembler language hides instructions behind mnemonics

1:1 relationship is not hiding.

>introduces pseudo-operations that have no relation to the machine

nobody forces you to use them.

>>999945 (OP)

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.

>>1000302

>any legit use case for this?

Yes. The general homoiconic nature of machine code is valuable. It's typically easy to use code as data than vice versa, however.

>1:1 relationship is not hiding.

I mean rather than thinking about the actual instruction, you must recall whatever the mnemonic is. My tool binds them to keys without names.

>nobody forces you to use them.

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.

>>1000307

>In a TL;DR version - an assembler that shows opcodes and the bit patterns in memory?

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.

>What I dislike about general assembly is, it's too high a level language compared to how things used to be.

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?

>>1000563

>This seems to actually be good software, I am looking foward for your final implementation of this tool.

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.

>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?

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.

>Also, assuming one commit to memorize hex values of an instruction set, do such person can benefit from your tool in any way?

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.

>>1000491

>Yes. The general homoiconic nature of machine code is valuable. It's typically easy to use code as data than vice versa, however.

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

>>1000491

>I mean rather than thinking about the actual instruction, you must recall whatever the mnemonic is. My tool binds them to keys without names.

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?

>>1000694

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

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.

>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)

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.

>>1000766

>What even is the point of this?

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.

>>1000776

>so the best example for CHIP-8 is perhaps using code as sprites.

MissingNo flashbacks

>>999959

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)

>>999945 (OP)

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.

>>1000776

>>1000491

>Also natively does reverse engineering / debugging by design

I like. I wish you well OP.

It's good to see an actual /tech/ thread with good content.

>>1000926

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

>>1001111

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

>>1001114

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

Just today I finished updating some articles I've written relating to this tool:

>A Documenting of the Coin Flipping CHIP-8 Game

http://verisimilitudes.net/2018-08-18

>A Documenting of the Russian Roulette CHIP-8 Game

http://verisimilitudes.net/2018-08-28

>A Documenting of my Fizzbuzz CHIP-8 Program

http://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.

>>1002236

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:

http://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.

>>1001302

>He can't do that on a single command

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

>>1001302

>linux

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 another update, I intend to have an ECMA_48 Ada package finished by 2018-01-31.

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.

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

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.

>>1032415

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

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

>>999945 (OP)

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:

http://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.

>>1037847

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

>>1040521

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.

>>1049304

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

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

>>1052720

>development logs

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.

>>1000031

>Well, x86 is an architecture that doesn't even work well with an assembler

why not go for RISC then

>>1054788

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

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://Prince-Trippy@verisimilitudes.net

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.

>>1052918

>>1049304

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

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.

>>1000031

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

>>1000280

>I seem to be the only person who's experimenting with creating a nice environment for machine code programming

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

>>1000280

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

>>1066315

>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"?

I have a single Easter egg planned.

>>1066325

>What got you started in this? Where you creating vydia for a graphing calculator?

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.

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

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

>>1066327

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

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.

>>1066328

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

I appreciate the kind words.

I've a new documenting; it's also available over Gopher, of course:

http://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.

>>1066363

> I have a single Easter egg planned

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

Any python coder here? Need help on a file based encryption.