On Tue, Jan 03, 2012 at 12:14:09AM +0100, Tomasz Rola wrote: > On Mon, 2 Jan 2012, Kragen Javier Sitaker wrote: > > Hi! May I post your response, and this response to it, to kragen-discuss? > > Sure, no problem. If you find this mail of enough value, you can also > repost it. Small edits are ok to me, I trust that you will do it well.
Thanks! > > You can probably get something running on an Arduino (using their IDE, not > > Forth) with US$20 and half an hour. Try it, it'll be fun! > > Yes, I read some blog entries (ditto with "half an hour" in their titles). > I might try Arduino one day, but frankly I like to compute on some bigger > scale. Perhaps I would be ok with few kilowords of ram, but with 8-bit > words... well, this fills so small... On IBM 704, they had 4-32Kwords but > a word was 36-bit. One could put some data into it and I guess, 36-bit > arithmetic was there in hardware. This was enough to make first LISP > interpreter on it. Generally speaking you need about 4KiB of memory to run a self-hosted interactive development environment, maybe 8KiB to run a more full-featured one. The ATMega328 has 32KiB of program memory plus 2KiB of RAM and 1KiB of EEPROM. Interpreters like Bitlash use the EEPROM to store the code to be interpreted. (But Bitlash seems pretty disappointing to me.) On the other hand, the 704 ran at "up to" 40 kips; the first wave of BASIC-programmable home computers ran at up to 300 kips (comparable to the 704 or faster, depending on what you were doing; I imagine the 704 was a bit faster doing 36-bit division); Wikipedia claims the Super Foonly F-1 (the fastest PDP-10 ever built) was clocked at 10-11MHz and so could presumably reach some 0.5-5MIPS; and the Arduino runs at 16MIPS normally. So the usual space-time tradeoffs mean the Arduino can probably get by with less memory, being faster. The 704 was also sufficient to write the first FORTRAN compiler and to synthesize speech. (Presumably it controlled external oscillators rather than generating PCM directly.) > Nowadays, one can really have other options that look more sexy to me > - like, FPGA + 128MB of ram, packed into USB stick or something equally > small. I am unable to find the page right now, but from what I remember > pricewise it was competitive to A* (especially when comparing what could > be packed into them). That sounds impressive. Do you already have VHDL synthesis software for the FPGA? Because I think they're usually kind of a pain to program. Don't underestimate the power of making it easy to get started on something. > So, I like small things but I also want them to have some usable power - > something comparable to PDP-10 or similar machine would probably make me > happy, especially for few tens of dollars. I am not into them right now, > but I can easily wait a bit and by the time I'm ready their prices will be > even more interesting, I guess. As mentioned above, the Arduino is already in the same speed class as PDP-10s were, but of course PDP-10s often had a megabyte or so --- 32 ATMega328s worth. Digi-Key sells ATMega328s in quantity 100 for US$2.20 each <http://search.digikey.com/us/en/products/ATMEGA328-PU/ATMEGA328-PU-ND/2271026> putting your superfast parallel PDP-10 at US$66 or so --- more than an Arduino, but not much. And whatever code you wrote for the Arduino, you could run on one node of your AVR hypercube. You could even use the Arduino as a programming board, and the Arduino bootloader to burn new code into the nodes in situ. But you could probably hook up a megabyte of external memory more cheaply than that. I haven't been able to find *new* external memory chips at a reasonable price on Digi-Key, but surely you could work out something with 30-pin or 36-pin SIMMs, which must surely be available in large quantities for next to nothing. > About 8-bits - I have nothing against them but, well, not really much can > be done with 8-bit cpu. It can be great fun on one hand, but on the other > hand once I laid my fingers on my first 16-bit computer (that was Amiga > and was, actually, almost 32-bit - muls and divs were 16bits AFAIR) I have > never looked back. Ditto for 32-bits. And now I am slowly migrating to 64. I don't know, they seem to be adequate for a lot of things. I'm getting this one to synthesize music and video in real time. > All my enthusiasm for 8-bit flattens when I recall that maybe I would be > able to make character terminal with it, but would have to connect to > someting bigger if I wanted to do anything useful for my current > activities... What are your current activities? > BTW, Arduinos might find themselves on a warming up ice. From the upper > side, there are coming all kind of 32-bit ARM boards and FPGAs. From the > lower side, there are plenty of cheaper 8-bit cpus, like Atmels or even > 8051. So far, Arduinos win because they are easy to begin with and to > tinker later - but this comes at some price. So even if I choosed them, I > would want to switch one way or another, a bit later. I suspect that sooner or later the Arduino is going to have to switch to either ARM (LPC11xx?) or AVR32. Code written using just the Arduino libraries should be pretty easy to port. > > Forth. > > > > ...With C, the compiler detects if I pass the wrong number of arguments to a > > function, or if I have a type error, but not if I have unbounded stack > > depth or if my execution time is nondeterministic. With Forth, the > > compiler won't even detect if I pass the wrong number of arguments or try > > to dereference an integer. > > Actually, I think you can't pass it wrong number of arguments - either there > is enough values on stack, in which case it will work, even erratically, or > there is not enough, in which case I believe it will stop with error. Most Forth systems do not in fact check for stack underflow after every instruction! On a general-purpose CPU, that would slow them down considerably. Most typical is to check for stack underflow before printing the prompt. Such errors don't necessarily result in stack underflows or leftover values, though. Consider this situation. I erroneously think that function f takes two arguments and returns one return value, so I try to write `3 * f(4, 5)`, as `3 4 5 f *`. Unbeknownst to me, f actually takes three arguments and returns two return values, so what I've written is actually `a * b where a, b = f(3, 4, 5)`. Similarly, if f actually takes one argument and returns nothing, the same code means `f(5); 3 * 4`. Testing interactively will usually tell me if I have a stack underflow, but even if I'm testing interactively, leftover values can escape my notice for a while. Forth systems, unlike e.g. GhostScript, traditionally don't tell you the depth of the data stack at each prompt, so you won't notice the extra value until you .s or it causes a problem in some other word. > > <http://www.yosefk.com/blog/my-history-with-forth-stack-machines.html>, > > after ending up with 700 lines of code like `dup um* nip FRAC 2 * 32 - > > rshift -rot`. In the comments, Samuel Falvo calls this "*the* classic > > beginners Forth problem -- way way WAY too many items on the data > > stack." > > This is very interesting article, and it even tought me few new things > about Forth :-) . > > However, I think he fell into a trap of very different kind than you > mention. Simply, Forth is not for everyone. To use it requires sometimes > even rephrasing a problem, to an equivalent form that matches Forth > capabilities. He was a guy in a middle of a bigger firm, had to use his > people and Forth could not fit there as a programming language. I can see how you might think that, since that's what he thought, too. But the particular way that Forth failed to fit was that the programmer, Yossi, didn't know Forth well enough to be able to write decent code in it. But the problem he was running into wasn't very deep, and probably could have been fixed pretty easily. They might have run into some other problem. > With another team and people using Forth on a daily basis for a longer > time, the story might have ended differently. But this could require, for > example, totally different hardware from the one described in a story. They were actually designing the hardware as they went, and they revamped it to match Forth. > > Here are some of the problems global variables cause in C and related > > languages: > > > > > 1. They live in a single global namespace, so if you try to define two > > variables with the same name, you get link errors. Or you get a > > single variable, being used by two different pieces of code that > > shouldn't be interacting at all, causing bugs in them. And it's hard > > to find all the references to the variable, because they could be > > anywhere in the program. > > > 2. It's possible to have an execution path that fails to initialize > > them, leaving values from a previous execution, leading to subtle > > bugs. In effect, they give persistent state to a part of the system > > that doesn't need it, and stateless code is always more reliable and > > easier to test. > > > 3. In a recursive call, every activation record of a subroutine has its > > own instance of its local variables. Recursion is still a somewhat > > tricky construct --- you have termination concerns that don't arise > > with nonrecursive calls, plus potentially unbounded stack usage > > potentially causing data corruption (on the Arduino and similar > > environments) or a program crash --- but it's less tricky when each > > call has its own local variables. > > > 4. Multithreaded access to global variables requires synchronization > > between the threads, or you get subtle race-condition bugs. > > Yes. Those problems, without thinking on them too deeply, all seem to stem > from the tiny architecture. With 1MB of ram, proper mem mgmt routines and > compiler that knows how to generate code, they would probably be gone. No, those problems get a lot worse with bigger programs. They're not nearly as bad if you only have 2KiB of RAM! Kragen -- To unsubscribe: http://lists.canonical.org/mailman/listinfo/kragen-discuss
