Muckin About

Another day hacking around inside - too lazy/warm to do the yard, and mum was down anyway, so was socialising during the morning. Hacking is more interesting anyway.

Kept poking around with the FORTH code, and managed to fix a couple more things. Silly mistakes like using the jonesforth versions of words rather than the (standard) ones I wrote. Got a rough POSTPONE implemented, but only for non-immediate words. And now, der, i've got a nice chicken and egg since I need it to implement IF (the way i'm doing it) and I need IF to implement POSTPONE properly. Ahh well; just have do it in ASM instead I guess, it's only trivial anyway. So I finally started filling out the higher level words, although not terribly quickly. Need to work out how to bootstrap it too ... ideally I would use a cross-compiler to generate everything into a memory image, but as the code compilation process itself extends the compiler, it makes things a bit more `interesting'. I'll think about whether that's worth worrying about (almost certainly not with this toy implementation), but to start with I guess i'll just compile it as part of the booting process on the target host.

Had a go over of the weekend at trying to get AI-OS (from the Touch Book) to work on the beagleboard, but unfortunately it looks like it no longer works on this hardware. Or I just did something wrong - i'm using a HDD since I don't have a big enough SD card and there's definitely stuff that hardcodes the SD slot. I finally got it to start booting using an Angstrom kernel, ... and then minicom crashed during the boot-up process, so I don't know why it hung - or even if it did at all, but after a few minutes I hit the reset button. And now when I try to boot the kernel just crashes with a NULL pointer, so it must've upset something on the SD card in the process. Ahh well it wasn't like I was expecting much ...

Also read a bit about Google's Go language. I can't remember if i'd heard about it before (maybe I have?), but I never looked too closely until now. Hmm, sounds fairly interesting ... might have to play with that next.

And today I also had another go looking at the ARM port of Haiku. Finally! The compiler builds! No more obscure error which makes no sense! Well that's a pretty good start anyway. Managed to get it to build (with a small fix for a renamed type), but am still working out the disk image building and Das U-Boot stuff so that's as far as i've gotten so far.

OMAP Exceptions

After basically doing nothing at all for a week apart from eat, sleep, and whine on the internet, I finally got off my arse (figuratively speaking only, sigh) and did a little more hacking.

I got a little exception handling bolted onto the FORTH code so at least now when it crashes I have a hint where it was, as well as don't have to reset the machine. I'd given up on it after wasting hours trying to get anything working a week ago ... all because of a silly missing .align directive. Bummer. And I wasted a few today too.

And I don't even need it anymore anyway!

ABORT: Exception Prefetch Abort
 pc: 52423020 sr: 200001D0
 r0: 8000E5C8
 r1: 00000082
 r2: 8000E5C0
 r3: 00000046
 r4: 8000E5D8
 r5: 8000E61C
 r6: 8001E5BC
 r7: 8000E5C0
 r8: 8000C008
 r9: 00000000
r10: 8000E5D4
r11: 8000D190
r12: 8000C094
r13: 8000E194 00000000 00020010 000008D4 8000B45C 00000000 00020010 000008E1 80009024
r14: 800092CC
r15: 00000000

Well isn't that impressive. Pity it doesn't really help with the bugs in my code. Although at least it does then simply jump back to the FORTH interpreter loop, so at least I don't have to resort to a hardware reset to continue.

I also changed the forth interpreter to run in user mode. Not because I really need to, but because I was too lazy to handle the exception stack pointer properly - since it was running in supervisor mode it uses the same stack pointer as the segfault-type exceptions. Probably it should run in system mode ...

Exception Setup

The following is just info for the few who might be looking for it - it took me a little while to dig it all up solely because I kept looking in the wrong places. It's not terribly interesting unless you're writing a kernel with no prior experience, it's not good code, and it's not even correct in many cases, but maybe there's something useful here for somebody.

The 'exception vectors' on the beagle are stored in the last few bytes of the omap's onboard 64K of RAM, and it is a jump table, not a function pointer array. Although they're actually setup so that there's room to use a function array immediately afterward by doing a pc-relative load, since 4 bytes isn't enough to do much else. The vectors start at 0x4020ffc8, although the Cortex-A8 also has a system control coprocessor register (c12) to move it.

So the init function just copies a 'prototype' image of the code across:

 // initialise exception vectors
 .global ex_init
ex_init:
 ldr r2,=ex_vect
 ldr r3,=0x4020ffc8
 ldr r1,=v_end_vect

1: ldr r0,[r2],#4
 str r0,[r3],#4
 cmp r2,r1
 blo 1b

 bx lr

ex_vect:
        ldr     pc, v_undefined_instruction
        ldr     pc, v_software_interrupt
        ldr     pc, v_prefetch_abort
        ldr     pc, v_data_abort
        ldr     pc, v_not_used
        ldr     pc, v_irq
        ldr     pc, v_fiq

v_undefined_instruction: .word ex_undefined_instruction
v_software_interrupt:    .word ex_software_interrupt
v_prefetch_abort:        .word ex_prefetch_abort
v_data_abort:            .word ex_data_abort
v_not_used:              .word ex_not_used
v_irq:                   .word ex_irq
v_fiq:                   .word ex_fiq
v_end_vect:

Where the ex_* labels mark the exception handlers themselves.

NOTE: it's missing the stuff to muck about with the caches, which is pretty important when you're writing code as data ... but for now it works. Perhaps I could avoid the code copy by just copying the address table ... I just don't know if I can assume that, or just use the system control register to move the table.

This is the first thing being done after Das U-Boot has executed the 'kernel image' - the only other thing i'm doing is setting stack pointer somewhere 'known'. I'm not entirely sure of the whole system state at this point (perhaps 'cpu powered up, and in supervisor mode' is all one can assume), so I don't even know if/what caches are even enabled for example.

Exception usage

Since all I want to do is dump some state and reset the interpreter, my exception handlers all do the same thing (apart from recording which one was invoked), but normally each exception type needs the correct return operations at least. It doesn't handle irqs properly either (right now i'd just like to know if they happen for no reason).

For simplicity my exception handlers just set a specific stack pointer on entry to do their work. That's because each processor mode and a few of the exceptions have their own shadow stack and link registers, and the only way to initialise them is to be in the right mode first. Again, too lazy.

After that they save all the register state to memory, and then call some C to dump the state, before jumping back to the FORTH ABORT code, with a reset back to user mode.

So an example of a specific handler (although I use a macro):

ex_prefetch_abort:
 ldr sp,=EX_STACK
 push { r0 }
 ldr r0,=3
 b ex_handle

Then it executes:

ex_handle:
 push { r0 }
 ldr r0, =ex_regsave+4

 // save original registers
 stm r0, { r1-r14 }^

 // save exception type
 pop { r1 }
 str r1,[r0, #-16]
 pop { r1 }
 // save pc, sr, and r0
 str lr, [r0, #-8]
 str r1, [r0, #-4]
 mrs r1, spsr
 str r1, [r0, #-12]

 // display something about it
 sub r0,r0,#16
 bl exception_dump

 // Now we want to reset everything and jump back to the forth loop
 ldr r14,=DOABORT
 movs pc,r14

The final movs also restores the CPSR and thus the processor mode.

Note: This is by no means particularly pretty or nice code. It was just the first thing I got working!

And the data-structure for passing to C:

 .data
ex_type: .word 0
ex_regsr: .word 0
ex_regpc: .word 0
ex_regsave: .word 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

And finally the C code.

struct exception_detail {
 uint32 type;
 uint32 sr;
 uint32 pc;
 uint32 reg[16];
};

const char const *extypes[8] = {
 "Reset",
 "Undefined Instruction",
 "Software Interrupt",
 "Prefetch Abort",
 "Data Abort",
 "Not used",
 "IRQ",
 "FIQ"
};

void exception_dump(struct exception_detail *e) {
 int i;

 send("\r\n\r\nABORT: Exception ");
 send(extypes[e->type]);
 ...
}

Can't help but mention it.

Apparently it's been on the news all over the place. It starts with a horrible name, and it just goes down-hill from there to make what can only be described as a horribly anti-human device. What was it again, the iMaxiPadTouch? Ho ho.

The name is bad, but then again, mums are buying wee's aren't they.

The hardware is pretty limited too. Ok so they have an interesting

~~multi-core (arm?)~~

-ish ARM processor, but the screen resolution isn't that high, the device isn't that light, and for the price the storage is pretty limited. But the real anti-customer feature is the lack of standard connectivity options. Sure you can get an ugly USB dongle, or an ugly SD-card dongle (but not at the same time). But why aren't they built in? What about HDMI? Could it be they don't want you to expand it on your own? Not even a camera? Props for the CPU and battery life, but the rest is a (big) fail mark. Even a PSP has more connectivity and expansion options built in!

And the software. It's a phone os. They might be ok on phones, but really, what sort of nonsense is it putting a phone os on what is really a general purpose computer? A locked down proprietary system that only allows you to get software from a closed network service. What year is this again, is this 1990 calling? The lack of multitasking is inexcusable - that's 1980 calling. Not having macromedia flash seems reasonable to understand (flash does suck) until you realise it's just another vector for controlling what media you can access, particularly, and specifically I suggest, locking out free media and those horrible free games (that people nonetheless love to play). This is the same reason Java is not supported. It's not about performance or security, it's about control.

Which brings me neatly to the media aspect. This is a device whose specific aims (if any can really be discerned) is to turn the free internet into a paid-for proprietary and locked-down service. It wants to turn everyone into a 'consumer' of corporate produced paid-for content channeled through their own toll-booth. I don't think a more anti-customer, anti-choice, anti-web '2.0', anti-progress and anti-freedom device has ever been created (a title that would make even Microsoft blush).

This is a very strange device. None of the benefits of a phone or media player (small size, camera) and none of the benefits of a laptop or even 'netbook' (open platform, expansion and connectivity options, real keyboard). It's too big to carry everywhere, and it's too useless to want to - it's really just a hand-held TV/set top box combo you can use to read the paper on the toilet (but isn't as useful if you run out of dunny paper), but there's no reason to take it further than your front gate. And apart from just being 'bad value' like most Apple Inc hardware, this device should be avoided like the plague if you have any respect for our cultural progress due to its draconian control of media content and software.

Compare this to something like the idea of the Touch Book (unfortunately the software in particular isn't quite there yet). Less memory, a bit slower - but lower price. 7(!) usb ports, 4 of which are internal to the machine, a machine you are expressly allowed to open. A replaceable SDHC card for OS and storage. Multiple operating system choices, far wider media support. A user replaceable battery. No digital restrictions management (DRM) telling you what you can do with your own data on your own machine. A half-decent keyboard, or simply use standard USB or blue-tooth keyboards. You can use it to write your own software. music, or create art, and learn about computers, not just consume paid-for content like some sort of slime-mould with no brain or creative spark of your own. The software side is still lacking, but that's only a matter of time before this or another device makes it.

Really the choice couldn't be more stark, and this is a perfect demonstration of why Free Software really matters. Do we want the future of our computers - and thus our society and culture which is now entirely dependent upon them - to be a shuttered, uncreative, paid for, controlled, and censored one, or an open, investigative and free one?

No amount of some balding, badly shaven, middle-aged poof in a black skivvy sitting on La-Z-Boy proclaiming how innovative the iTampon is makes it true. If he really believes that this is the most important product he's launched then you can add senile to that list too, or if he doesn't, then outright liar. The only innovation will be if they somehow convince a large number of people to buy such a nasty, anti-human device.

GNU/Linux out-competes another company ...

So Sun has cleared the final (?) hurdle to being bought by Oracle. Well good for them, a lot of smart cookies will keep their jobs to feed themselves for another day. I do feel a bit sad about it - like many, SunOS was my introduction to Unix 19 years ago, and Sun was always one of those 'cool' companies, they made nice looking hardware and weren't just about marketing hype; they had meat under those feathers too. Were they the last true technology company?

In less than 10 years, they've gone from basically running the .com bubble to running out of money, and here's one major reason: GNU/Linux.

Oh sure they could've done things a bit differently - such as free Solaris or Java a bit earlier, but I don't think it would've made much difference in the end. As microsoft are finding - it's pretty hard to compete with `everyone', particularly when it's free. And it's not just the price - free also to take mind-share which is the real killer for any technology company. That GNU/Linux was pretty much a 'Solaris clone' from the start surely didn't help either (I did much of my earliest GNOME code on Solaris - the code was easily ported to Linux).

I wonder which company will be next?

You'll be censored!

If I did it right, hopefully you got a (at least) slightly alarming popup box about the planned government censorship during this week. See more details at The Great Australian Internet Blackout site.

I guess 66% of my visitors are from overseas and the other one knows about it already, but I thought it was an interesting form of protest ...

Bumbling along like a ...

Well, A/C supposed to be fixed today. Finally a service tech was called and came yesterday, and a couple of minutes on the roof and he was ordering a new control unit. Dodgy caps not too uncommon apparently. But because of the increased demand they don't have any spares ... hopefully that's all it is, as it's just in the nick of time - weather starting to turn hot.

Kept bumbling along with my FORTH attempt. Would really help if I concentrated a bit better, but lack of sleep and so on. Not entirely switched on. Still, making some progress.

I decided to standardise some of the basic words, which meant a lot of breakage. But I more or less have that going, and implemented DOES>, which jonesforth didn't implement. These changes mean I wont be able to use much of the bootstrap for jonesforth either - but I guess that will just make it a better learning exercise, wont it.

I'm still sticking with assembly where possible, although considering just using c for call-outs to significant processing steps; that's basically how the assembly is written anyway. I'm finding reading the standard a bit tough going - understandably it's target audience is really people who have a lot of experience with FORTH implementations already.

It's a huge mess though, but perhaps now some of the basics are starting to work I can think about cleaning it up a bit. Then add a few bits and pieces and then start trying to use it. I want to add some hardware exception handling at least, so crashes aren't fatal. And I need to be able to input from memory to bootstrap the code. Well something to keep poking at I guess.

The saga continues ...

Well to answer the question posed two articles ago - nobody uses those old things anymore. Just had the sparkie around and he wired the a/c on a separate breaker (probably as it should have been in the first place) and moved the kitchen/laundry to a breaker too. He said they only come across those fuses when dismantling old fuse boxes.

So all that done, time for a hot coffee.

But the a/c didn't work either - panel did all the right things, pump too, just no air being pushed ... then it blew the breaker. So another visit from the installation guys basically just to confirm it's just broken and now a call's been lodged with the manufacturer for a 'service call'. Hopefully it's just a bung controller.

The insulation guy eventually rocked up yesterday too - and I had it installed by the end of the day. I suspect there's an awful lot of roofs in Adelaide that fall within the 100sqm limit of the 'average house' (hah, asif). Quite painless, although who knows how effective it is - they split some of the bats up to lay over the old stuff.

FORTH

Mucked about with the FORTH some more, with all the interruptions and comings and goings that didn't happen till the evening - and then about 9pm I noticed it was dark. Not sure if that's a good thing or a bad thing (I definitely know that the 2 packets of chips and beer I had for lunchdinner[sic] was a bad thing though!). But as you'd expect given that it was a new processor to me, and that I was too tired and interrupted most of the time I was working on it - almost everything was wrong. Wrong registers in places, wrong order of registers, incorrect memory calculations and so on and so forth. But after many many iterations of fixing one function at a time I finally got something that compiled basic functions ok.: a 42 EMIT ;

a

*

Well, "yay".

The current INTERPRET loop processes every character as it receives it - with no line editing and so on, so I thought about improving that. Didn't feel like writing that in assembly, so I fell back to C (TBH the compiler does a very good job with ARM code for the most part - but the core FORTH works better in assembly). I wrote a simple little 'readline' function with basic editing for single line input (cursor keys, delete, backspace etc) using terminal escape codes. That should do the job to start with once I hook it in.

As an exercise I thought i'd port it to FORTH instead. I was quite surprised - it (well, on paper - I don't have enough bootstrapped to build it yet) came out smaller (well no surprise there) and easier to read than the C equivalent. There's a few ugly bits but they can be hidden (or written better - no expert here). That's really what makes FORTH an interesting language, because you actively extend the language or add trivial functions to hide details without any penalty (in runtime or source baggage) for doing so. And it is real language extension including syntax, not just the run-time library. In-fact, since a threaded-interpreted run-time is so small I imagine the original powerful concept was that you could even radically alter that if need-be, although I think standardisation efforts muted the use of that `feature' to some extent.

I do think it falls down a bit on the variable front - they all work as explicit pointers, although I noticed there are now 'newer' concepts like 'values' that abstract some of messiness (and inefficiencies) away. And generally this stuff can be hidden away from most of the code.

Anyway, I'm quite enjoying this, so I'll see where it takes me, i've already got some ideas for tweaking the implementation and so on. Tho I'd better get outside and fill the bin with rubbish today as well, or it'll never get moved.

About Me

Tags

Haiku @ Beagle