1 Jan
2009
1 Jan
'09
12:48 p.m.
Chapter 8 of "Advances in Computer
Architecture" describes the SYMBOL computer, designed
and built buy Fairchild Camera, and operated at Iowa State. Only one was built.
And that one is in the CHM collection. I have found some documentation for it, but no
software.
1 Jan
1 Jan
1:38 p.m.
Al Kossow wrote:
Very cool. Do you know if it is the complete machine? Any schematics? How large is it?
It makes me wonder if it could be implemented on an FPGA. With today's design
languages,
it wouldn't be very difficult to create a tool chain that could turn a BNF description
into a netlist -- BNF -> verilog, verilog->gates. I'm sure one thing that was
very
daunting back then was any small change to the language would result in massive changes to
the wiring.
Of course there would be no reason for carrying it out, but it is fun to think about.
Even if you could build such an FPGA and got it going at 100 MHz, it would still be slower
than a conventional compiler running on a 2 GHz x86. Despite the increased efficiency, it
is hard to bridge that 20x clock multiplier. The best you could do is improve on the
start up time, but for any code that iterated, the compiler would win as the parsing costs
are paid only once.
Chapter 8 of
"Advances in Computer Architecture" describes the SYMBOL
computer,
designed
and built buy Fairchild Camera, and operated at
Iowa State. Only one
was built.
And that one is in the CHM collection. I have found some documentation
for it, but no software. 
4:18 p.m.
On Jan 1, 2009, at 1:38 PM, Jim Battle wrote:
Very cool. Do you know if it is the complete machine? Any
schematics? How large is it?
It makes me wonder if it could be implemented on an FPGA. With
today's design languages, it wouldn't be very difficult to create a
tool chain that could turn a BNF description into a netlist -- BNF -
Oooh, that'd be serious fun!
Chapter 8 of "Advances in Computer
Architecture" describes the
SYMBOL computer, designed
and built buy Fairchild Camera, and operated at
Iowa State.
Only one was built.
And that one is in the CHM collection. I have found some
documentation for it, but no software. verilog, verilog->gates. I'm sure one
thing that was very
daunting back then was any small change to the language would
result in massive changes to the wiring. Of course there would be no reason for carrying it
out, but it is
fun to think about.
Nono, think of the architectural research that this would
facilitate! Aside from just being fun, one could do some seriously
interesting architectural work with something like this.
Even if you could build such an FPGA and got it going
at 100 MHz,
it would still be slower than a conventional compiler running on a
2 GHz x86. Despite the increased efficiency, it is hard to bridge
that 20x clock multiplier. The best you could do is improve on the
start up time, but for any code that iterated, the compiler would
win as the parsing costs are paid only once.
I dunno, those x86s are pretty darn inefficient.
-Dave
--
Dave McGuire
Port Charlotte, FL
4:30 p.m.
bfranchuk at jetnet.ab.ca wrote:
Dave McGuire wrote:
spelling error line 8 - recursion
Nono, think of the architectural research that
this would
facilitate! Aside from just being fun, one could do some seriously
interesting architectural work with something like this.
Um how do you do recusion? Dave McGuire
Port Charlotte, FL
5:23 p.m.
bfranchuk at jetnet.ab.ca wrote:
bfranchuk at jetnet.ab.ca wrote:
> Dave McGuire wrote:
>
>> Nono, think of the architectural research that this would
>> facilitate! Aside from just being fun, one could do some seriously
>> interesting architectural work with something like this.
>
> Um how do you do recusion?
like anyone else -- with RAM and a pointer. the parser could be as simple as looking at
one byte of input text per clock, or it could perhaps have a window of the next, say, 8
bytes looking forward in the stream, and decode entire tokens in a single clock.
if the parsing logic hit "A - (B - C)", the state machine would
look up "A" in the symbol table and retrieve its value (or hold an index to
it) and
place it on a value stack
the "-" operator would be pushed on an operator stack
"(" is pushed on the operator stack
the "B" would be looked up, and saved on the value stack
the "-" would be looked up, and since it has higher precedence than the top
of the
operator stack [which is "("], "-" would be pushed on the operator
stack too.
the "C" would be looked up and saved on the value stack
the ")" is lower precedence than "-", so "-" is popped
off the operator stack, and
since it is dyadic, the B and C values would be popped off the value stack and operated
on. the ")" is checked against the top of the operator stack; we find the
"(" and pop it.
if we found another operator instead, say unary "-", that would have been
processed
first. the operator stack is still non-empty, as "-" is found, so it is popped.
since it
is dyadic, the "B-C" value is popped and "A" value is popped and
operated on. the
operator stack is empty, and the expression is complete.
a dirt simple state machine can carry that out; a smarter one delays pushing results in
hopes that the next step needs the just computed result anyway. error processing would
complicate things to know how far to rewind the stack. one could opt to have dedicated
operator/value stacks, but then there would be a hard limit for the depth of expression
nesting. This is manageable for Dartmouth BASIC, but more of a problem for a language
with scoping.
the best solution is to logically have the stacks in main memory, but to cache the top N
entries from each FIFO.
6029
days inactive
6029
days old
5 comments
4 participants
participants (4)
-
aek＠bitsavers.org -
bfranchuk＠jetnet.ab.ca -
frustum＠pacbell.net -
mcguire＠neurotica.com