ANN: Embedded processor for Tcl language
Scott Thibault
processor for the Tcl language. More information, and a recent presentation
is available at: http://www.gmvhdl.com/acrodesign/research.html#tob
--Scott Thibault
AcroDesign Technologies
Phil Tomson
Hmmmm.... so this is basically a FPGA implementation of the Tcl virtual
machine? (actually, I wasn't aware that Tcl had a bytecode interpreter,
but I guess it isn't surprising).
Phil
Nicholas C. Weaver
Phil Tomson <pt...@shell1.aracnet.com> wrote:
>Hmmmm.... so this is basically a FPGA implementation of the Tcl virtual
>machine? (actually, I wasn't aware that Tcl had a bytecode interpreter,
>but I guess it isn't surprising).
Well, TCL is more a ascii string munging hack, based around textual
replacement, so you could treat the program as a (really ugly)
bytecode.
Why you would WANT to however, is beyond me. Compile scheme or
something to a nice vanilla uP core and have hardware support for
garbage collection.
--
Nicholas C. Weaver nwe...@cs.berkeley.edu
Scott Thibault
That bytecode is not suitable for hardware implementation, however. We
designed a special bytecode for this purpose, and yes, the FPGA is like a
virtual machine for this bytecode.
--Scott
"Phil Tomson" <pt...@shell1.aracnet.com> wrote in message
news:anf7e...@enews3.newsguy.com...
Scott Thibault
news:anf99u$2h35$1...@agate.berkeley.edu...
> In article <anf7e...@enews3.newsguy.com>,
> Phil Tomson <pt...@shell1.aracnet.com> wrote:
> >Hmmmm.... so this is basically a FPGA implementation of the Tcl virtual
> >machine? (actually, I wasn't aware that Tcl had a bytecode interpreter,
> >but I guess it isn't surprising).
>
> Well, TCL is more a ascii string munging hack, based around textual
> replacement, so you could treat the program as a (really ugly)
> bytecode.
Tcl was originally implemented as a string processing engine, but can be
described in more traditional terms just as other languages (i.e., a BNF
grammer, compilers, etc.)
>
> Why you would WANT to however, is beyond me. Compile scheme or
> something to a nice vanilla uP core and have hardware support for
> garbage collection.
>
Tcl is not so different from Scheme if you replace []'s with ()'s, but ...
there are a couple of advantages to using Tcl. First, memory is managed with
reference counting, which is simple and predictable. Second, the extensive
built-in string processing abilities that very are useful for embedded
devices that communicate using command based protocols over TCP. There are
other advantages such as being easy to learn and pointer safe etc.
We compiled to a custom processor because compiling very high-level
languages to a vanilla processor can generate large executables, and our
target was a memory constrained device.
--Scott
Jim Granville
>
> Tcl interpreter uses a bytecode compiler internally to improve performance.
> That bytecode is not suitable for hardware implementation, however. We
> designed a special bytecode for this purpose, and yes, the FPGA is like a
> virtual machine for this bytecode.
>
> --Scott
Sounds interesting - Can you post a small example of the flows ?
- something like tiny source code / intermediate sizes / final speed,
and size of the Tcl engine itself.. ?
Not everyone here will know Tcl in detail, but the general
application of script handling within FPGA is usefull to get a handle
on.
- jg
Nicholas C. Weaver
Scott Thibault <thib...@gmvhdl.com> wrote:
>Tcl is not so different from Scheme if you replace []'s with ()'s, but ...
Actually, its a big difference due to scoping rules. Tcl's scope
semantics (dynamic scope) is a BUG, but a bug which arrises from its
original incarnation as string munging which meant that it couldn't
have proper closures.
This is a big issue as the Tcl/TK windowing model is rightly patterend
around the notion of binding closures to events. Yet binding closures
to events are much more predictible and useful with lexical scope, a
total nightmare with dynamic scope.
>there are a couple of advantages to using Tcl. First, memory is managed with
>reference counting, which is simple and predictable.
Only because Tcl doesn't allow real structures & references.
Reference counting can't collect cyclic structures.
Utku Ozcan
Very sensible. Modelsim uses a Tcl bytecode virtual machine, like JVM.
A very interesting processor design project. I wonder whether the bytecode
instruction set is public or a custom set?
Utku
Scott Thibault
provides an HTTP interface to a hypothetical zoned climate controller. The
final object code size including OS/Network stack/Program was 32K. CPU
processing for an HTTP request was about a second on a processor running at
5MHz.
--Scott
# write new zone data to the controller
proc update_zone {zone no assign} {
set pos [expr [string first "=" $assign] + 1]
set val [string range $assign $pos end]
write_reg [expr ($zone << 1) + $no - 2] $val
}
# read zone data and format into HTML
proc zonehtml {zone no} {
set data [read_reg [expr ($zone << 1) + $no - 2]]
set hour24 [expr ($data >> 10) & 31]
if {$hour24 > 12} {
set hour12 [expr $hour24 - 12]
} else {
set hour12 $hour24
}
set quarter [expr ($data >> 8) & 3]
set min [expr ($quarter << 4) - $quarter]
set temp [expr $data & 255]
if {$hour24 == 24 || $hour24 < 12} {
set ret [format "<TD>%d @ %d:%02d am</TD>" $temp $hour12 $min]
} else {
set ret [format "<TD>%d @ %d:%02d pm</TD>" $temp $hour12 $min]
}
return $ret
}
# process an incomming HTTP request
proc www_req {handle} {
set req [split [gets $handle] " ?+"]
set loc [lindex $req 1] # get file name part of URL
puts $handle "<HTML><BODY>"
switch $loc {
/current {
puts $handle "<TABLE border=5><TR><TD>Zone 1</TD><TD>Zone
2</TD></TR>"
set l [join [list "<TR>" [zonehtml 1 0] [zonehtml 2 0] "</TR>"]]
puts $handle $l
set l [join [list "<TR>" [zonehtml 1 1] [zonehtml 2 1] "</TR>"]]
puts $handle $l
puts $handle "</TABLE>"
}
/update {
update_zone 1 0 [lindex $req 2]
update_zone 1 1 [lindex $req 3]
update_zone 2 0 [lindex $req 4]
update_zone 2 1 [lindex $req 5]
puts $handle "Request completed."
}
}
puts $handle "</BODY></HTML>"
close $handle
}
# accept a new HTTP connection
proc accept {handle ip port} {
# create a callback to "www_req" whenever the new connection becomes
readable
fileevent $handle readable [mk_cmd www_req $handle]
}
proc main {} {
# initialize device driver
set fd [init_dev]
# start PPP server with IP address 192.158.0.25
ppp_attach $fd [list 192 168 0 25]
# create TCP server on port 80 (HTTP) with the callback procedure
"accept"
socket -server accept 80
while {1} {
update
}
}
"Jim Granville" <jim.gr...@designtools.co.nz> wrote in message
news:3D9CA7...@designtools.co.nz...
Scott Thibault
> In article <upolcln...@corp.supernews.com>,
> Scott Thibault <thib...@gmvhdl.com> wrote:
>
> >Tcl is not so different from Scheme if you replace []'s with ()'s, but
...
>
> Actually, its a big difference due to scoping rules. Tcl's scope
> semantics (dynamic scope) is a BUG, but a bug which arrises from its
> original incarnation as string munging which meant that it couldn't
> have proper closures.
The default behavior is not dynamic scoping without explicit use of the
uplevel or upvar commands. We do not support this in our compiler.
> >there are a couple of advantages to using Tcl. First, memory is managed
with
> >reference counting, which is simple and predictable.
>
> Only because Tcl doesn't allow real structures & references.
> Reference counting can't collect cyclic structures.
Yes, and there is an important application space that does not need them,
and can benefit from refrence counting.
--Scott
ham...@cloud.net.au
> Very sensible. Modelsim uses a Tcl bytecode virtual machine, like JVM.
Really? Where did you get this information?
I confess that I find Tcl to be one of the most awful languages I have
ever used. IMHO it has no virtue whatsoever.
Hamish
--
Hamish Moffatt VK3SB <ham...@debian.org> <ham...@cloud.net.au>
Nicholas C. Weaver
<ham...@cloud.net.au> wrote:
>I confess that I find Tcl to be one of the most awful languages I have
>ever used. IMHO it has no virtue whatsoever.
It has one virtue, it drove the development of TK, which is quite
tolerable when used with something like Scheme to make Scheme/Tk.
Phil Tomson
>> Very sensible. Modelsim uses a Tcl bytecode virtual machine, like JVM.
>
>Really? Where did you get this information?
>
If you've ever used ModelSim you'll notice that they allow you to script
simulations with Tcl - which strongly implies that there is a Tcl
interpreter embedded in ModelSim. Also, I believe that the ModelSim GUI
is implemented in Tcl/Tk.
>I confess that I find Tcl to be one of the most awful languages I have
>ever used. IMHO it has no virtue whatsoever.
>
I would tend to agree with you, especially when you compare it to an
elegant language like Ruby (http://rubycentral.org), for example.
However, Tcl has been around for a while so there tend to be a lot of
folks who know it and it's easy to embed Tcl in applications written in
C/C++. I suspect that it's the latter reason that Tcl is used in
ModelSim and several other EDA apps.
There are better languages available now than Tcl (such as Ruby) but it
might take a while before we start seeing them show up embedded in EDA
apps. Also, I suspect that a hardware implementation of Ruby would be a
lot more difficult to do than this hardware implementation of Tcl given
the dynamic nature of Ruby (the same could be said for Python too, I
suppose).
Phil
Allan Herriman
wrote:
>In article <3d9fa193$0$22176$afc3...@news.optusnet.com.au>,
> <ham...@cloud.net.au> wrote:
>>Utku Ozcan <utku....@netas.com.tr.nospam> wrote:
>>> Very sensible. Modelsim uses a Tcl bytecode virtual machine, like JVM.
>>
>>Really? Where did you get this information?
>>
>
>If you've ever used ModelSim you'll notice that they allow you to script
>simulations with Tcl - which strongly implies that there is a Tcl
>interpreter embedded in ModelSim. Also, I believe that the ModelSim GUI
>is implemented in Tcl/Tk.
From http://www.tcl.tk/doc/compiler.html
"Tcl 8.0 introduced an on-the-fly byte-code compiler for Tcl."
I just learned something. I had always thought that Tcl was purely
interpreted.
Regards,
Allan.
ham...@cloud.net.au
> In article <3d9fa193$0$22176$afc3...@news.optusnet.com.au>,
> <ham...@cloud.net.au> wrote:
>>Utku Ozcan <utku....@netas.com.tr.nospam> wrote:
>>> Very sensible. Modelsim uses a Tcl bytecode virtual machine, like JVM.
>>Really? Where did you get this information?
>
> If you've ever used ModelSim you'll notice that they allow you to script
> simulations with Tcl - which strongly implies that there is a Tcl
> interpreter embedded in ModelSim. Also, I believe that the ModelSim GUI
> is implemented in Tcl/Tk.
I'm aware that it has a Tcl interpreter, but haven't seen any evidence
that there's any compilation going on. It's pretty obvious that plain
old tclsh doesn't do any compilation, because if you change the source
file on disk while you're running it it gets confused!
ModelSim SE allows you to use Tk in user Tcl scripts, but PE doesn't.
> However, Tcl has been around for a while so there tend to be a lot of
> folks who know it and it's easy to embed Tcl in applications written in
> C/C++. I suspect that it's the latter reason that Tcl is used in
> ModelSim and several other EDA apps.
I'm quite a fan of Perl. IMHO every VHDL or Verilog developer could
benefit from a basic knowledge of Perl and particularly its regular
expressions. And Tcl as well, because so many of the tools have
integrated Tcl (ModelSim, Synplify, ...)
It might be that Perl wouldn't make a very good interactive shell
though. Perl certainly has its share of haters, most of whom are Python
users now I think.
Cheers,
ham...@cloud.net.au
> From http://www.tcl.tk/doc/compiler.html
> "Tcl 8.0 introduced an on-the-fly byte-code compiler for Tcl."
"On-the-fly" doesn't seem to be an advantage. Tcl still can't detect
even basic syntax errors in advance. I can just imagine writing a Tcl
script that collects samples for a week, then bombs out with a syntax
error just before writing the report.
Admittedly Perl doesn't detect missing subroutines in advance, but it
does detect syntax errors.
Phil Tomson
<ham...@cloud.net.au> wrote:
>Phil Tomson <pt...@shell1.aracnet.com> wrote:
>
>> However, Tcl has been around for a while so there tend to be a lot of
>> folks who know it and it's easy to embed Tcl in applications written in
>> C/C++. I suspect that it's the latter reason that Tcl is used in
>> ModelSim and several other EDA apps.
>
>I'm quite a fan of Perl. IMHO every VHDL or Verilog developer could
>benefit from a basic knowledge of Perl and particularly its regular
>expressions.
I could say the same about Ruby.... And Ruby's regular expressions are
are quite similar to Perl's with one exception: Ruby's regular expressions
are actually objects which can be manipulated as objects whereas Perl's
aren't.
>And Tcl as well, because so many of the tools have
>integrated Tcl (ModelSim, Synplify, ...)
>
>It might be that Perl wouldn't make a very good interactive shell
>though. Perl certainly has its share of haters, most of whom are Python
>users now I think.
Well, I wouldn't put myself in the Perl-hating class, I guess I'd say I'm
a reformed Perl programmer. I programmed in
Perl for six or seven years and even did object oriented Perl - actually,
that's when I decided there must be a better way since OO Perl is so ugly.
Tried Python but didn't like that indentation was part of syntax and also
didn't like the fact that you had to pass self into all of your instance
methods. But Ruby was a good fit - it has the regex facilities of Perl
but it's much cleaner especially when it comes to object oriented
programming. Since Ruby was developed to be object oriented from the
ground up it's much more consistent than Perl is and I find that I have to
reach for the manual a lot less than I did with Perl. This consisency
tends to make Ruby a joy to program in. If you haven't tried it, check it
out: http://www.ruby-lang.org
Phil