Post screenshots of stuff you're working on!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Post screenshots of stuff you're working on!

Wedge of Lime: Sep 4, 2003; I lack indie hair superpowers.

tef posted:

I wrote some code to glue our processes at work together. It evolved enough to warrant splitting off and rewriting chunks. I got permission to MIT license it and stick it on github.

http://github.com/tef/hate-rpc

I'll hopefully carve out more time to work on it, but it is just a little beyond the prototype stage and the documentation makes it look like english is not my first language.

Looks interesting, I'll watch your progress.

I've just read through the README file, I can see why you might want to use a different serialisation format than JSON for this.

At work we use JSON extensively for our internal web api's and I'd be interested if you could expand a bit on the 'hosed up unicode' support in JSON as its not a problem I've hit, yet.

# ¿ Feb 25, 2012 11:51

Adbot: ADBOT LOVES YOU

# ¿ Apr 26, 2024 07:39

Wedge of Lime: Sep 4, 2003; I lack indie hair superpowers.

For a while now I've been working on developing a tracing library for a user land driver under Linux on an embedded arm device called the Allwinner A10.

Here is a screen shot of the output. Its not especially exciting to look at but quite a lot of work went into it. Especially the instruction parsing and processing.

I've got my code up on github with more details https://github.com/iainb/CedarXWrapper if anyone wants to take a look.

# ¿ Aug 13, 2012 20:35

Wedge of Lime: Sep 4, 2003; I lack indie hair superpowers.

hendersa posted:

This is a nice piece of work. Simple and clean. I thought you were taking an strace/truss approach to get the libc calls that wrap system calls, but I can see that you've got wrappers in wrap.c to handle those. That would explain why you're showing so few functions in your output... you're only catching ioctl() calls and some memory ops.

The user land driver doesn't really do much other than memory operations and some ioctls. So without the memory ops you don't really observe anything useful at all.

For example tracing the playback of a tiny 500Kb h264 file produces about 5Mb of output.

hendersa posted:

I don't usually see opcode cases like you have in instructions.c, though. Your way is very clean and logically grouped, and more intuitive to follow. I usually see a big, honking switch statement for every single interesting opcode/addressing mode combo with a default case at the bottom for whatever opcodes you don't care about. The big switch statement is for speed, since you avoid multiple comparisons on each opcode to whittle down to the special case that you want. That way is all about performance. If it isn't that much of a slow down for you, then your way is much easier to follow.

Thanks, I mainly split up the instruction parsing so I could understand what was going on. Parsing the instruction, performing the required operation and recording the result is quite tricky.

Initially I did start with a big switch statement but it became unmanageable, so I decided I'd sacrifice speed for readability. Currently it takes about 60-80ms to decode a small h264 frame while tracing.

# ¿ Aug 13, 2012 22:24

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Post screenshots of stuff you're working on!