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.
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.
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 ;
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.
Copyright (C) 2018 Michael Zucchi, All Rights Reserved.Powered by gcc & me!