Recent blog entries for brejc8

IM BBS: news directly to your instant messenger

I have been working on this IM BBS idea for a couple of weeks now. Its basically a bulleting board which you can connect to using your instant messenger. Currently the most useful function is the direct RSS link delivery. Every time there is a new entry in an RSS feed you are subscribed to the thing messages you the story and a link. Much more convenient to receive an interrupt than polling by repetitively hitting refresh on the slashdot page.

I have had some time off recently so I concentrated on my pet projects. One of these being a "mapper" to find people who are similar and group them together. Its working quite well and the php frontend is very easy to write. So far I have just made up some little pointless questions (a lot of them were submitted by others). Strangest thing is the correlation between the different maps.
For example this is a map of Tea (blue) vs Coffee (red)
It has a very similar layout as the C (red) vs Java (blue)

I have finally released KMD version 0.9.11 under GPL.

KMD is a graphical debugger. It can debug hardware over serial ports such as the Manchester ARM Board or with software emulators (ARM and MIPS emulators are included in the project). Using the pipe option you can debug over the network or any other communication medium. It can load many executable formats such as ELF and display and follow the original source even from multiple source file programs. There is support for breakpoints and watchpoints which can trap specific instructions (such as loading or executing specific instructions). Support for other features such as FPGA's is also available, allowing loading or any control required to drive a specific hardware device. The project uses chump to allow disassembly and line assembly. Chump also allows new architectures to be easily added without the need to recompile the system. Communication with the backend is done using two pipes/fifos using a simple set of codes. Back end communication program can be created using very little memory on the target device.

Distributed Mirror Project
I was thinking about doing this for some time and after considering some rather complex methods I decided that this one is as good as any.
"Distributed Mirror Project" is a method of creating mirrors and distributing the information that you are hosting a mirror to others. There are two main sections of it.
Firstly there is your end. Using a script you can easily make a mirror of a site and then submit the information that you have a mirror of a site or a file to the server site.
The other end is the server site which collects the information about the mirrors. It then allows users to search for mirrors of sites or files.
Its really as simple as that. The download a site and submit the information to a mirror server script is three lines. The server end is a little more complex but I am very happy about the way its working so far.
Try it out. (It won't work with some characters yet but thats next on the todo list)

chump

chump is currently a single line assembler and disassembler. This is fine for now when used to enter instructions on the fly into KMD. The next milestone will hopefully be able to assamble programs. This requires some additions into the system.

Firstly the system will have to cope with lables reather than strict numbers. Numbers are easy to process because you can find and scan them quite easily but lables which might not have been defined yet could be a little more tricky.

Forward lables (i.e. branches or loads etc. pointing to lables later in the code) are even more difficult. Many instruction sets have several branch types for different distances and consume different ammounts of space. The first pass will not be able to know how far the target is. Taking the worst case stratergy and reassembling individual lines in later passes is probably the best way to do this but this does not get over the issue of instruction sets like ARM where it is not the distance but the number of significant bits. This could lead to infinate loops.

The first pass should recognise all lables and read all instructions into a list.

Pass two takes the instructions and assambles them. If relative forward looking instructions need an address forward the worst case size is taken. All relative instructions are marked as "to_be_reassabmled".

Pass three reassambles each "to_be_reassambled" instruction and when it finds a smaller version it replaces it (thus changing the address of later instructions and lables). After each optimisation all relative instructions which look over the optimised instruction (forwards only) will be reassambled (again).

I havent started thinking about macros or preassembler operations. There are obveous places (between pass 1 and 2) where they fit in.

chump

There have been two main additions to chump. Firstly it allows enumerations to get rid of the laboreous process of defining long consecutive lists like registers.

  (enum 2 "r0" "r1" "r2" "r3")

reather than

  (("r0")(OO)) (("r1")(OI)) (("r2")(OI)) (("r3")(II))

The second addition is the ability to have inline C type structuures in the assembler. Its nice to be able to have lines like:

  while (r1 > r2) sub r1, r1, r2;

Or even larger structures like:

  do {add r1, r1, #1; ldrb r0, [r2, r1];}
  while (r0 != #0)

These are easily defined in the chump code and generate several instructions. The disassembler can generate more C like code, but this is normally turned off.

Isn't perl lovely? I had a little play with it the other day and created a nice link page. Unfortunately coming back down to C is a little strange. I'm constantly thinking in high level languages. I maniged to convince someone to convince someone (not a mistake) to have a go at writing a good universal schematic capture package. It should be very useful.