Yurii Rashkovskii's Blog

We’ve decided to make an alpha IA-32-INSTRDB release (0.0.1). Your feedback and bug reports are highly appreciable!

You can download it here.

XI is able now to handle simple calls to CDECL functions:

[syntax,sexi/cdecl.sexi,lisp]

Probably, now I need to stop for a while, and think about making compilation transformations better and easier to develop. I need to write some Lisp macroses for most of typical instruction sets and scenarios.

P.S. I got a nice idea on XI/XIRO internals. It will require huge rewriting of current code, but it should be much better than continuing maintaining existing code. And anyway, details that was analyzed while working on the current code, are inappreciable for me. The idea is so obvious, so I ask myself, why I’m not doing all this stuff this way from the very start? If my idea idea will completely prove its viability, I’ll write about it here.

While working on XI compiler, I’ve published a small project for a x86 instructions database. It is a very simple one-table [SQLite] database that contains IA-32 instructions. It is not finished yet, but already could be useful and that is why I’m publishing it.

Warning: this entry is just a dump of my thoughts about XI’s garbage collecting, and it could be absolutely erroneous.

Mostly every s.c. `high level’ programming language has a garbage collector (GC). What GCs are for? They are used to (accorinding to Wikipedia):

1. Determine what data objects in a program will not be accessed in the future.
2. Reclaim the storage used by those objects

Nice. Now we can think about application of this functionality to XI objects (frames), do not forgetting about database nature of the system.

Please note that my English writing skills are pretty weak and the text that you can read below is far from perfect. Your help will be highly appreciated!

Ok. So, this entry is an attempt to make a brief introduction to XI, which is currently a main topic for this blog. I hope this will help you.

This morning I have fixed some aggravating bugs and finally was able to perform a transformation to X86 (compilation to native code) of a simple Linux system call construction:

[syntax,sexi/syscall.sexi,lisp]

This is a linked list that describes a system call write of a frame image-name to standard output with retrieving length of image-name.

It compiles to

[syntax,asm/sexi-syscall.asm,asm]

It is far from perfect, however, and I should think about better assembly, but the problem is that I have only a little experience with assembler. After reaching this point XIRO code became quite dirty, and I need to perform some code cleanup and refactoring, probably.And yes, XIRO executes this code and does not segfault.

You can look at XIRO code here.

Updated at 20:10 EEST. Now XIRO entry point is defined by following SEXI code:

[syntax,sexi/entrypoint.sexi,lisp]

It outputs the following line:

XIRO x86 (Build Saturday, July 1, 2006 08:09:49 PM)

P.S. As for SEXI format, just to make it clear, in short. Each frame is a list of 1+ values. First should be a name of a metaframe or list of names of metaframes. Then you could optionally specify a new frame name (prefixing name is colon). The next is value name, or value SEXI expression, or vector of values #(values …) or nil. The rest elements are either slot name or slot frame definition.

There is an important built-in support for linked-list. You could specify a linked-list just by using { item1 item2 … } syntax. If you have any questions, please contact me, I’ll try to describe all this stuff better (if somebody wants to!)