Forth Day and SEA Platform news?
Jason Damisch
and is there any news about the new Forth hardware?
Jason
tomg...@gmail.com
See the program on the website: Michael played some Bach music with
numerous "synthesised voices" using an Intellasys chip and thumb sized
board. I don't have knowledge of how computationally intensive it was,
but Ting, who has done simpler music synthesis, said he was
impressed.
Boards should be available in Jan 08, and the software is available
now on the web site. But I went to the web site and was not able to
get a response by email as advertised.
tg
Jason Damisch
> See the program on the website: Michael played some Bach music with
> numerous "synthesised voices" using an Intellasys chip and thumb sized
> board. I don't have knowledge of how computationally intensive it was,
> but Ting, who has done simpler music synthesis, said he was
> impressed.
I failed to locate where the program is on the site. Maybe I didn't
look hard enough. I could not log in with my old username and
password. Is it me or them?
Jason
Ian Osgood
Samuel Falvo also wrote up Forth Day in his blog.
http://www.falvotech.com/blog/index.php?/archives/200-Forth-Day-Report.html
SeaForth stole the show!
Ian
foxchip
> On Nov 20, 6:31 pm, Jason Damisch <jasondami...@yahoo.com> wrote:
>
> Samuel Falvo also wrote up Forth Day in his blog.
Samuel's blog is good. I could make a couple corrections
and a couple of additions. Bill's talk could have been about
many things based on the description but primarily it involved
a simple solution to the problems of navigating source code
directory trees on Windows, Mac, and Linux platforms without
using conditional compilation.
Chuck's first comment was that he liked seeing colorforth on
the screen without a windows frame around it. T18 and
colorforth okad code for SEAforth24 had been shown in earlier
presentations running hosted in Windows while Chuck prefers
to use the stand-alone version. Chuck's comment that he likes
colorforth without windows was appreciated by the audience.
Chuck has always been a big fan of self-modifying code and I
knew he would enjoy seeing how the !p+ opcode had been used to
do it in SEAforth. As a former Phd candidate in Mathematics
at Stanford Chuck has a bit more formal background in math
and logic training than most of us. He has said that he
thinks that it should be possible to prove mathematically that
self-modifying code will always be the smallest and fastest
code possible. (hardware doesn't allow it excepted of course.)
I spoke about the !p+ instruction history because it was one of
my babies coming from the F21 design. It was essentially the
most recently discovered and unpublished opcode from F21 which
came back in c18 with a a different name and a much more
valuable use in port executed code.
While some people don't like dramatic code optimization examples
I find that some other people say they are grateful to be
reminded of ways to make their programs smaller and faster and
let them be more productive in their work. One example was in
ANS Forth and was described as symptomatic of much code in c.l.f.
It served as nice example of how this testbed function had been
sped up 256000 times.
I also showed some simple SEAforth code in colorforth to control
servo motors used in robotics. I showed a first cut controlling
ten servos from one node and pausing every 2ms to process command
messages, and a second version supporting eighteen servo motors
and with pauses for command messages every 20ns. I showed how
the node could control up to 35 servos if I put more code on a
neighbor node with no pins. The example was to familiarize
people with colorforth code again on something simple and easy
to understand and to show how code evolves in a couple of hours
of work.
Chuck's 9X 3x3 board has with each 24x cluster chip 1 MW not
1 GB of DRAM for each cluster.
It was nice that Samuel could attend and he did a nice writeup
of his impressions of an SVFIG Forth Day. Thanks Sam.
I had tried to provide a skypecast of the proceedings but I had
never done it before and skype seemed to go down just before it
was suppose to start. Maybe someday someone at SVFIG will plug
in a webcam or provide a skypecast or remote webmeeting access
to presentations. Thanks for the url to Samuel's blog. It is
nice to see a writeup of a Forth Day.
Best Wishes,
Jeff Fox
hel...@gmail.com
> He has said that he
> thinks that it should be possible to prove mathematically that
> self-modifying code will always be the smallest and fastest
> code possible.
I'd like to hear more about it. Especially what assumptions are made
to prove this.
My idea would be:
mod-version:
C:
a b
a c
'd a !
C
'e a !
C
--
non-mod-version:
D:
d b
d c
E:
e b
e c
D
E
Which should be 1:1 at least (omitting "return"s and so on). This is
for the non-unrolled case. D and E could be inlined, which makes 2:3
in favour of non-modifying code. Well, this is the simplest case. I
also think that modifying code is a good thing to think about and that
it over all would be smaller (it would enforce re-use of code parts).
But the mathematical prove has to specify it's borders...
-Helmar
Marcel Hendrix
[..]
>> He has said that he
>> thinks that it should be possible to prove mathematically that
>> self-modifying code will always be the smallest and fastest
>> code possible.
> I'd like to hear more about it. Especially what assumptions are made
> to prove this.
The conjecture is obviously false. It claims to *always* be true,
so only a single counterexample is necessary to disprove it. Because
of the 'smallest AND fast' we can forget 'fast' and find a program
that is the same size or longer than the self-modifying one.
Given the following specification:
Write byte with value a to 32-bit memory location "b",
the program on a hypothetical 41-bit processor would need to be
bp:a
bp:b
bp:sto ; it was not specified that the program stops.
where bp: means "bit-pattern of", and "sto" is the appropriate store
instruction. Because both a and b are arbitrary, no assumptions can
be made. The sto bitpattern's length is at least 1 bit. So the program
will fit in exactly one word of memory (41 bits). Because a and b are
arbitrary, a selfmodifying program can not make this shorter . QED.
(I could also have specified a "stop" program on a processor with byte
instructions, but that would have been too easy.)
I assume Chuck formulated the statement quite differently.
-marcel
foxchip
> I'd like to hear more about it. Especially what assumptions are made
> to prove this.
Perhaps more emphasis should be on smallest since that should be
pretty obvious. A precise definition of self-modifying code might be
difficult because architectures are not neutral on the issue and are
influenced by instruction set and caching issues. There are
certainly designers that decided to make self-modifying code lose.
The context of Chuck's statements is pretty obvious. First he
has demonstrated how to get the code more dense then with the
ocmplicated pipelined cached register rich machines so to
start with they can't win on the making programs small, especially
if they try to use inlining. Is storing into a native-code
load-immediate's argument field self-modifying code?
So we must start with the kind of hardware and software that
Chuck talks about to understand any of his statements. Almost
anything he says can be declared false if one transposes it
to an opposite context where it doesn't apply. Remember that
over the years Pentium code has consistently been several
times larger than this type of code even with using self-
modifiying code to make the small code even smaller. So
one cannot disprove's Chuck's statements by trying to
switch to a context where more code is required in the first
place.
For a number of reasons including limited on-chip memory or cache
issues smaller may also be faster. There are usually multiple ways
to do things and the question becomes which introduces the least
overhead defered words inside of a loop or code that patches the
words in the inner loop? If you have a loop with ten million
iterations the defered overhead for defered words, bit it as
small as a jump, will be multiplied by ten million while the
self-modifying code version will have less overhead.
Could this cascaded looping structure be replicated N times?
Perhaps on some architectures and in some cases but given
real-world program and computer size constraints this may not
be possible or it might have other memory or cache issues.
What works on the trivial problem won't fit and may require
a smaller code approach when a more demanding application
is specified.
Chuck is usally talking about his experience with Forth software
for over four decades and his experience with Forth hardware
for several decades. And in that context there are very
different constraints than those that exist for people programming
in other languages or on hardware designed for other languages
or which introduce significant penalties to the sort of simple
code Chuck would prefer. Short instructions, tightly packed,
stack based not register based. To begin with designs
that make self-modifying code difficult are probably not even
in contention on code size.
Is building executable data structures on the fly and then
executing them considered self-modifying code? This is
generally considered a good thing in Forth and is a
foreign concept to batch compilers. There may be
a significant layer of inefficiency introduced if it isn't also
native-code. Is using a reverse-literal and then executing
the data field considered self-modifying code?
I can recall examples of self-modifying code from my early
Forth days where it allowed a solution. Graphics code was
possible, and fit, and using high-level words to patch a
few assembly routines let them run at higher speed than
if they had used even one level of indirection in the
inner loops. Loop unrolling would have not been possible
and would have really been against the idea of self-
modifying code being any help in making the program
smaller and faster.
Because architectures are not neutral one can create
an example where the code for the self-modification
looks as frequent as the code it modifies. But
consider the case where the modification happens much
less frequently than the modified code gets executed.
That's where you will have less total overhead than
with defered or vectored words executing their overhead
many times over.
> But the mathematical prove has to specify it's borders...
No proof was offered, just the suggestion that given the context
that applies to Chuck's statements about architecture and programming
the possibility of a mathematical proof should be reasonable.
Context is important. I think Chuck is probably right abouut this
one. I have never seen any evidence that he is not.
Best Wishes,
Jeff Fox
Jonah Thomas
> hel...@gmail.com writes
> [..]
> >> He has said that he
> >> thinks that it should be possible to prove mathematically that
> >> self-modifying code will always be the smallest and fastest
> >> code possible.
>
> > I'd like to hear more about it. Especially what assumptions are made
> > to prove this.
>
> The conjecture is obviously false. It claims to *always* be true,
> so only a single counterexample is necessary to disprove it.
If we suppose that self-modifying code includes non-self-modifying code
as a subset, then it's trivially true. When there's a way to use
self-modifying code to make the result smaller or faster, then
self-modifying code wins. Otherwise the fastest code can still run on
the self-modifying system even though it doesn't actually modify itself,
so it's still fastest.
If self-modifying code isn't allowed to include non-self-modifying code
then it's trivially false. Break the self-modifying code into pieces
that do simpler functions. Continue until you get a function that
doesn't benefit from self-modification. Consider a program that consists
only of that function. If you do self-modifying code anyway it won't be
smaller and faster. It would take a very special instruction set for
every instruction of every program to benefit from self-modification.
There are examples where self-modifying code works. The big problem with
using it is that many programmers aren't used to the challenges of
confirming exactly what conditions it is guaranteed to behave correctly,
or debugging their failures, and many managers prohibit its use by
reflex. If the goal is to require minimal effort to get something that
works, and then requkre minimal effort to maintain it, avoiding
self-modifying code would look like a no-brainer. Why compete for the
small pool of talented developers who are competent at self-modifying
code when you can draw from the much larger pool of programmers who
can't?
Marcel Hendrix
> m...@iae.nl (Marcel Hendrix) wrote:
[..]
>> The conjecture is obviously false. It claims to *always* be true,
>> so only a single counterexample is necessary to disprove it.
> If we suppose that self-modifying code includes non-self-modifying code
> as a subset, then it's trivially true.
[..]
> If self-modifying code isn't allowed to include non-self-modifying code
> then it's trivially false.
And therefore, the conjecture would be worthless (doesn't say anything new).
I think this means code fragments must be demonstrated that do not use
self-modification, and see if self-modification would make these either
smaller or faster. Again, if we can find only a few of these fragments, it
doesn't say anything, because the conjecture would then not say:
"It should be possible to prove mathematically that self-modifying code
will always be the smallest and fastest code possible."
but
"It should be possible to prove mathematically that self-modifying code
will sometimes be smaller and/or faster than non-self-modifying code."
Which is trivially true -- who would care to challenge this observation.
Now, to make a scientifically (not mathematically) interesting statement,
one could try to show that
"In a significant percentage of the real-world embedded programs presented
in this study, self-modifying code was smaller or faster than non-self-
modifying code ."
(You could just as well set out to prove the diametrically opposed statement,
with equally interesting results.)
This would be a significant amount of real work, and certainly be very
interesting when conducted scientifically.
It is unlikely that such a study will emanate from the OP, who has to my
knowledge never produced any *verifiable* numbers for anything. Or, going
with the spirit of this posting, let's self-modify that to "has not produced
any *verifiable* numbers in any CLF postings I have ever read from him."
For a serious study it will be necessary to define 'self-modifying code' more
carefully. For instance, is a Forth interpreter a self-modifying program? Is
a linker a tool to self-modify programs? How is self-modifying code
significantly different from run-time compiling/assembling a specialized
version of a generic routine
(e.g. in www.complang.tuwien.ac.at/forth/gforth/old/gforth-0.6.1.ps.gz )?
-marcel
Anton Ertl
>For a serious study it will be necessary to define 'self-modifying code' more
>carefully. For instance, is a Forth interpreter a self-modifying program?
I differentiate between self-modifying code (existing code is
changed), and run-time code generation (new code is generated at
run-time). Also, in the context of an interpreter, we have to
differentiate between native code and interpreted code. So, a Forth
interpreter necessarily does run-time code generation of interpreted
code.
BTW, many restrictions that hurt self-modifying (native) code also
hurt run-time (native) code generation.
> Is
>a linker a tool to self-modify programs?
A static linker is usually used to combine non-executable code into an
executable, and is usually not called by the program itself, so in the
usual case: no.
A dynamic linker can be used for doing things that one might also do
with self-modifying code. Moreover, in some cases it works by
modifying existing code.
>How is self-modifying code
>significantly different from run-time compiling/assembling a specialized
>version of a generic routine
It's much easier to make run-time code generation thread-safe, but
RTCG also uses more memory.
>(e.g. in www.complang.tuwien.ac.at/forth/gforth/old/gforth-0.6.1.ps.gz )?
That's a 200+-page document. I guess you mean stuff like:
BTW, I have recently come across work that uses self-modifying
(native) code profitably to specialize functions: Some papers from
this work (I have not read these, but those I have read had pretty bad
presentations):
http://polaris.cs.uiuc.edu/lcpc07/accepted/9_Final_Paper.pdf
http://www.prism.uvsq.fr/users/bad/Research/ps/INTERACT11KCB.pdf
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2007: http://www.complang.tuwien.ac.at/anton/euroforth2007/