My Best Teaching Is One-on-One

一対一が僕のベスト

Of course, I team teach and do special lessons, etc.

当然、先生方と共同レッスンも、特別レッスンの指導もします。

But my best work in the classroom is after the lesson is over --
going one-on-one,
helping individual students with their assignments.

しかし、僕の一番意味あると思っている仕事は、講義が終わってから、
一対一と
個人的にその課題の勉強を応援することです。

It's kind of like with computer programs, walking the client through hands-on.
The job isn't really done until the customer is using the program.

まあ、コンピュータプログラムにすると、得意先の方に出来上がった製品を体験させるようなことと思います。
役に立たない製品はまだ製品になっていないと同様です。

Friday, August 8, 2008

Looking Back to Go FORTH

A long, long time ago, back when dinasour mainframes roamed the earth, I was fresh back from my mission to Japan, trying to figure out what all LDS young men just back from their missions are trying to figure out: What do I do now?

But this little rant is less about that and more about one of the things I did. My brother, out of the kindness of his heart, gave me a 6800 prototyping board, I think it was the micro-chroma 68. Basically, it was the Radio Shack Color Computer, but with a 6800 instead of a 6809, or even a 6801. Okay, it was a 6802, but that was just a 6800 with some built-in RAM and ROM.

It's about 4000 miles away, so I can't post a picture, but that's okay. This rant is not so much about that piece of kit, either.

My brother dug up a ROM BASIC somewhere, but I wanted a better language. One of the teachers at the community college suggested FORTH, so I wrote off for the fig-FORTH model implementation for the 6800. The printout did not contain the object dump, so I had to go through the entire assembly listing and add the op-codes that had been abbreviated in the listing. I really did not think much of hand-assembling code at the time, writing it down seemed like more work than looking up the op-codes.

[I once had the insane urge to actually transcribe the source for that 6800 fig-FORTH. For a while, it was linked at forth.org, but they seem to have removed the link now. You can find it in the appropriate sub-directory of my 6800 assembler. Joel -- 2015-03-28]

I was silly enough to not build a floppy disk controller, but I did build a fast cassette tape controller, which was a little bit more reliable than the built-in 300 baud cassete tape controller. So I had some place to store the results after I typed the the entire model in in hexadecimal code. How long did it take? Don't remember, but it did seem like a long time, when I had friends and teachers playing around with the original IBM PCs, Apple ][s, and the like. Not to mention the time I wasted at Radio Shack playing around with the Color Computer demo models.

I don't think I can explain why I didn't just save up the money and get one of those Color Computers, with disk drive, etc. It sure would have saved me some time.

I think.

I played around with the FORTH, worked out the examples in Brodie's Starting Forth, as far as I could without disk drives. The dRAM was actually 64K, and I used a bit on the parallel port to toggle between banks, but I didn't really have the experience to figure out how I could usefully emulate a (very small, very volatile) floppy disk with it. So I was a little stuck on the disk examples. Also, the model provided hooks for implementing multi-tasking, but no actual implementation, so I wasn't able to play with that.

But I did learn enough FORTH to make me very impatient with other languages.

Fast forward to to when I got my associates and transferred to BYU. Found myself at the end of the BS-CS coursework with three class left, the one where you write a simple compiler, the one where you write a simple OS, and an elective. I was still spoiled by FORTH. (Maybe I still am.) Could not resign myself to stupidly hashing through simple closed algebrae and playing stupid register allocation games when I "knew" there was a better way. Kept trying to synthesize something useful from the two diametrically opposed approaches to computer languages, without the experience to know where the boundaries of object orientation were, to see where the difference between closed mathematical objects and infinite tape were always depositing me during my design attempts at random places in my own undefined memory.

Hey, I'm stronger for it. Right?

Anyway, those were my first flunked classes. I had, actually, a low A average to that point. Fortunately, BYU allows you to repeat classes. I took on the OS class first. Finally got up the courage and the wisdom to invest enough money to buy a Color Computer on sale, with Radio Shack's recommended cassette deck. (Yeah, I know about store recommendations, but it was also on sale. I could have saved another five dollars, but I'd have wasted a day running around.) Wrote screen routines and keyboard routines and time routines, and whatever else I could to pass the class.

The elective I chose was software tools. I went ahead and bought a disk drive and Radio Shack's disk-based assembler package, and implemented FORTH on the Color computer's 6809.

Actually, I got OS-9/6809 before I got the more basic assembler, and tried to do the FORTH in the OS-9 assembler, but found myself fighting with trying to make a relocatable FORTH, without fully understanding that I was effectively trying to define an i-code without actually pinning the codes down to specific values.

No, actually, I really did figure that out fairly quickly, but I just couldn't reconcile myself to the solution, you know, the one that put a 64K code limit on classes in early versions of Java -- Make the i-codes an index into an array, put the actual pointers in that array. Cry when you run out of array. Or not, if you never compile that many words.

One other option might have been possible, using self-relative i-codes. Needless to say, Microware's assembler would not assemble such a beast. For some reason, I declined writing an assembler that would. OS-9/6809's pre-ANSI C compiler might have been one of those reasons, or maybe I was just too lazy.

You have a similar problem when you try to use raw C language function pointers as i-codes. Most modern OSses relocate by keeping a list of addresses that need to be fixed up when the code is loaded. You can't help filling borked when you have to implement your own fix-up on an OS designed not to be fixed-up, and the fix-up table is as big as your object.

So I dropped my attempts to do it in OS-9, and went out and got the more primitive assembler software and worked with that. That way, I didn't have to think about relocation issues.

Once I had a simple enough implementation environment, the port was fairly straightforward. Or it should have been. First, assign the virtual registers of the FORTH model to real 6809 registers:

The return stack pointer, RP, was the 6809's call stack pointer, S.

The parameter stack pointer, SP, was the 6809's user stack pointer, U.

The i-code instruction pointer, IP, was the 6809's Y index, but I would sometimes save it off temporarily when I needed two index registers.

I put W on the top of the return stack, if I remember right. A little weird, but it was out-of-the-way, and still accessible.

You might think I'd use DP for the user variable pointer. But that sure was an awkward idea, DP being only the top eight bits. I ended up putting most (all) of the headerless primitive words in the DP and using DP relative jumps to get there, which was not a good idea, either. Oh. I also put the user variable pointer in the DP, too.

I designed the symbol table structure as a nested binary tree instead of using the more typical hashing techniques. That facilitated a certain amount of information hiding, for modularity and other object-ish behaviors.

Then I wrote the primitives, the inner interpreter, the basic parser, the symbol table lookup, the basic math. At a certain point, I had enough primitives that I could have finished off by just typing in the rest of the fig-forth high level model's compiled form. But the teacher wanted to be sure I was not just copying, so I re-wrote some of the stuff where it looked like 6809 object would actually be smaller than the high-level object. Used a kind of stupid-code-trick approach to shifting between high-level object and 6809 object on the fly (mostly stupid because shifting gears is not really a good idea, other than showing the teacher that you understand what it's doing at some level.

Once I had the 6800 model converted to 6809, with my modifications, I copied the fig editor source into a screens disk and had a running system. Source code was about a hundred 60-line pages, the object a bit fatter than I had expected, just over 8K if I remember right.

Then the teacher asked me to document every word in the model, so I did that. By hand. On paper. Don't know why I did it by hand, on paper. I later typed it into a text file, and that is also a part of the download on my site, linked again here, in case you missed it above. (Just what you always wanted, wasn't it?) All of that took me about six months, working pretty much full-time on the project. (Thanks go to my parents for letting me live in their attic for a while.)

[My personal website is now off-line until such time as I can afford $20 a year or so to pay dyn.com or someone else to resolve the url for me on an on-going basis, I guess. See the bif-c link below, and look in the appropriate subdirectory for the source code. -- Joel 2015-03-28]

I ended up passing my compiler class with a compiler written on that FORTH. So my education was all FORTH colored. Maybe that's why I just gave up on the industry about two and a half years ago. Maybe I can do something about it [link added 2 May 2011] while I'm taking a break.

No comments: