Older blog entries for brejc8 (starting at number 4)

15 Jul 2003 (updated 15 Jul 2003 at 14:56 UTC) »

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)
4 Jan 2003 (updated 4 Jan 2003 at 23:34 UTC) »
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.

30 Dec 2002 (updated 30 Dec 2002 at 20:34 UTC) »
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.
29 Dec 2002 (updated 30 Dec 2002 at 12:25 UTC) »

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.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!