nested call
Bernd Paysan
>
> Does anyone know...
> In a normal forth application, how many nested calls would be involved?
Not too many; it certainly depends on the size of the application. Small
apps don't nest too deep.
> I'm thinking to port a forth for Microchip's PIC.
> We are currently using PIC 16c73, it only has 8 calling stack. and interrupt
> will
> take one. so only 7 available... I'm afraid that it's impossible to port
> forth on it...
There is a Forth (or let's say, a somewhat Forth-like language) for the
PIC 16c84, from Michael Josefsson, it's on Taygeta
(http://www.taygeta.com/forthcomp.html, download from
ftp://ftp.taygeta.com/pub/Forth/Compilers/cross/PIC/f2pic.exe)
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
cLIeNUX user
>"JC
>>
>> Does anyone know...
>> In a normal forth application, how many nested calls would be involved?
>
>Not too many; it certainly depends on the size of the application. Small
>apps don't nest too deep.
The FRISC3 decided on a 16 cell return stack (before a refresh) by looking
at existing code. 7 is tight, but you can do a lot in 7. 4 was too tight
even for Chuck Moore on the MuP21 as I recall.
Rick Hohenseek
Michael N. Steen
Bernd Paysan <bpa...@mikron.de> skrev i en
nyhedsmeddelelse:3A811AD3...@mikron.de...
>
> There is a Forth (or let's say, a somewhat Forth-like language) for the
> PIC 16c84, from Michael Josefsson, it's on Taygeta
> (http://www.taygeta.com/forthcomp.html, download from
> ftp://ftp.taygeta.com/pub/Forth/Compilers/cross/PIC/f2pic.exe)
>
> --
and there is a (commersial) Forth for the PIC16 series available from RAM
Technologies, UK http://www.ram-tech.co.uk/index.htm. It's a target compiler
and ICE build on top of FPC for the PC.
There's even a freeware version for the PIC16C84 (and PIC16F84) only, see
http://www.ram-tech.co.uk/picmicro.htm
Best regards
Michael Steen
Tony Williams
JC <jc1234567 <@> yahoo.com> wrote:
> I'm thinking to port a forth for Microchip's PIC.
> We are currently using PIC 16c73, it only has 8 calling
> stack. and interrupt will take one. so only 7 available...
> I'm afraid that it's impossible to port forth on it...
I've used a Forth target compiler for a number
of PIC programmes. Certainly the very first
prog written overflowed the stack (trapped as
an error message when compiling). Subsequent
programmes (even large ones) seem to rarely
exceed a depth of 4 on the PIC's stack.
The trick, if there is one, is to get out of
the habit of excessive factoring. Especially
factoring that is there simply in order to
make the final prog "look nice". Indeed, it
is far better for the most inner routines to
be done as inline macros....... set/reset of
single bits being the most obvious examples.
--
Tony Williams.
Jeff Fox
> 7 is tight, but you can do a lot in 7. 4 was too tight
> even for Chuck Moore on the MuP21 as I recall.
If you mean that Chuck had to occasionally do return stack
spill/fills then yes, 4 was too tight. Chuck was happy
with the return stack depth on P21 for his code however.
It was I who requested the deeper stacks on F21 for my code.
> Does anyone know...
> In a normal forth application, how many nested calls
> would be involved?
It all depends on what you define as normal. I have
seen Forth code that required megabyte depth return stacks in
one extreme, 64K depth stacks, 256 cell deep stacks, and
minimally 3 cell deep return stack on the other end.
After a few years of dealing with 4 cell deep return stacks
I came to see the upgrade to a 17 cell deep return stack
as "virtually infinite" as Chuck says. Chuck felt that
4 was adequate and 17 was excessive. I had originally
specified the minimal number specified by ANS. With only
a 4 cell deep return stack I had to manage stack spill
fills a small percent of the time in my code.
> I'm thinking to port a forth for Microchip's PIC.
> We are currently using PIC 16c73, it only has 8 calling stack.
> and interrupt will take one. so only 7 available...
> I'm afraid that it's impossible to port forth on it...
>
> any opinions?
Chuck Moore's first VLSI chip, MuP21, which was produced
in 1994, had only 4 cells in the on-chip return stack. Chuck
modeled it on the requirements of his VLSI CAD software.
He felt this was sufficient for good Forth code.
There is no stack spill and fill hardware on the chips.
If nested calls go deeper than 4 it is the responsibility
of the compiler, human or computer, to manage stack spill
and fill to memory. This represents a very small percent
of the total code typically, but it depends of course
on the code in question. In looking at the OK code in Machine
Forth I see a couple of places where the return stack is
spilled and refilled.
Chuck uses tail-recursion and inlining of primitives to
save return stack cells and uses words recursively without
any return stack overhead. Recursion need not be avoided
because of fear of some large return stack overhead.
Chuck also does not use the return stack as a control
flow stack in the traditional DO LOOP way. But even with
shallow stacks he factors mercilously.
In Phil Koopman's book on Stack Computers
http://www.cs.cmu.edu/People/koopman/stack_computers/index.html
he gives some
numbers for the percentage of stack spill/fill code
relative to on-chip stack depths. In his chip taxonomy
8 or more is considered the line from medium to large.
ANS does not specify minimal stack depths. Version
3 of the draft did specify 28 and 32 cells as the minimal
number of stack cells (I forget which was 28 and which was
32) but that went away before the offical release.
Sent via Deja.com
http://www.deja.com/
Stephen Pelc
>We are currently using PIC 16c73, it only has 8 calling stack. and
interrupt
>will
>take one. so only 7 available... I'm afraid that it's impossible to
port
>forth on it...
Its linked from the vendor page at www.forth.org
Alan and his clients use this for real-world applications.
--
Stephen Pelc, s...@mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)2380 631441, fax: +44 (0)2380 339691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads!
Tony Williams
Michael N. Steen <m.s...@get2net.dk> wrote:
> and there is a (commersial) Forth for the PIC16 series available
> from RAM Technologies, UK http://www.ram-tech.co.uk/index.htm.
> It's a target compiler and ICE build on top of FPC for the PC.
It's quite nice and when you have to drop into
assembler you find that it is not reverse polish.
It is (nearly) identical to the syntax laid out
in the PIC data sheets.
I dislike reverse polish assemblers. "Only 1.5KB
of source code" is of no importance imo, I'd
rather have 10KB of source code, with the computer
having to do the work of mental translation off
the mfr's data sheet, not me.
--
Tony Williams.
Andrew Haley
> I dislike reverse polish assemblers. "Only 1.5KB
> of source code" is of no importance imo, I'd
> rather have 10KB of source code, with the computer
> having to do the work of mental translation off
> the mfr's data sheet, not me.
I always thought the great advantage of Reverse Polish assemblers
isn't how small they are but how well they fit into the language's
expression syntax. To match a real manufacturer's assembler would
require a full operator precedence parser; not very Forth.
I also love having high-level looping constructs.
Andrew.
Gary Chanson
Tony Williams <to...@ledelec.demon.co.uk> wrote in message
news:4a49a5a...@ledelec.demon.co.uk...
>
> It's quite nice and when you have to drop into
> assembler you find that it is not reverse polish.
> It is (nearly) identical to the syntax laid out
> in the PIC data sheets.
>
> I dislike reverse polish assemblers. "Only 1.5KB
> of source code" is of no importance imo, I'd
> rather have 10KB of source code, with the computer
> having to do the work of mental translation off
> the mfr's data sheet, not me.
I disagree. I agree that size isn't significant, but I want my
assembler to be RPN. It's WELL worth the small extra effort in exchange for
having the full use of the Forth interpreter in constructing operands, etc.
The extra effort should be very small and very natural for an experienced
Forth programmer.
--
-GJC
-gcha...@shore.net
-Abolish Public Schools.
Jerry Avins
What extra effort? When I'm switching back and Forth, It's easier to
star in one mindset.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Jerry Avins
What extra effort? When I'm switching back and Forth, It's easier to
stay in one mindset.
Tony Williams
Andrew Haley <a...@aph.demon.co.uk> wrote:
> I always thought the great advantage of Reverse Polish assemblers
> isn't how small they are but how well they fit into the language's
> expression syntax.
>
I see an assembler as an application that happens
to be written in Forth. There is no need for it
to be Forthlike, far from it. The Reference Document
is the uP mfr's datasheet and what is written in
there is what the user should have to type, in the
order given. Why impose another level of mental
gymnastics to do? Why not let the computer do the
mental gymnastics, that's what it was bought for.
> To match a real manufacturer's assembler would require
> a full operator precedence parser; not very Forth.
Alan Robertson seem to have done it though, you can
read a PIC instr in the data sheet and (more or less)
type it in, in the order that Microchip wrote it.
> I also love having high-level looping constructs.
And Alan's assembly-level IF THEN (etc) constructs.
--
Tony Williams.
Jerry Avins
It's all a matter of what one likes. I generally programmed 8080s using
Zilog mnemonics because I preferred to. I have my druthers and you have
yours. I enjoy talking about them --up to a point -- as long as no one
seems to be proselytizing.
Gary Chanson
Jerry Avins <j...@ieee.org> wrote in message
news:3A83193F...@ieee.org...
>
> What extra effort? When I'm switching back and Forth, It's easier to
> stay in one mindset.
The extra effort is when you have to translate the Intel documentation
into RPN.
Gary Chanson
>
> > To match a real manufacturer's assembler would require
> > a full operator precedence parser; not very Forth.
>
> Alan Robertson seem to have done it though, you can
> read a PIC instr in the data sheet and (more or less)
> type it in, in the order that Microchip wrote it.
The point is not that it can be done (of course it can), but whether
it's desirable. I feel strongly that it is not. It is far more desirable
to have RPN syntax because it fits the Forth environment better. In an RPN
assembler, any Forth expression can be used to generate operands, data, etc.
The typical RPN assembler also supports Forth structured conditionals
instead of the brain-dead branches of a foreign assembler.
J Thomas
> Tony Williams <to...@ledelec.demon.co.uk> wrote in message
> > > To match a real manufacturer's assembler would require
> > > a full operator precedence parser; not very Forth.
> > Alan Robertson seem to have done it though, you can
> > read a PIC instr in the data sheet and (more or less)
> > type it in, in the order that Microchip wrote it.
> The point is not that it can be done (of course it can), but
> whether it's desirable. I feel strongly that it is not. It is far
> more desirable to have RPN syntax because it fits the Forth environment
> better. In an RPN assembler, any Forth expression can be used to
> generate operands, data, etc.
> The typical RPN assembler also supports Forth structured conditionals
> instead of the brain-dead branches of a foreign assembler.
I figure, if I have to write and maintain an assembler myself, I want it
to be easy to write and maintain. At least the first version will be
RPN because that saves me trouble.
From there it depends. If I'm mostly doing Forth with some simple
inner-loop stuff in assembler, I don't need any more of an assembler
than that. I don't care about the data sheet that much, I'm going to
write small definitions that I'll thoroughly test anyway, and once I
build up a body of assembler code I can search it for examples of
similar constructions to the one I'm not sure how to write -- or if I
get confused by my assembler I'll rewrite a little to make it easier.
The other extreme, if I have to import a lot of somebody else's
assembler code written with an alien assembler, I'll like it much more
if my assembler reads the particular formats the code I need uses, and I
want it to compile the same machine code that the source code expects.
It becomes worth it to rewrite the assembler to meet my new needs.
If I buy an assembler with a Forth system, then I want it to do it both
ways, whichever way I prefer at the moment. It's more trouble to write
an assembler like that, but that's part of what I'm paying for. It
might cause me trouble later to have some of my code RPN and some not,
but I want to decide which format to use when I need to decide, not
before I buy the system.
Tony Williams
Jerry Avins <j...@ieee.org> wrote:
> It's all a matter of what one likes. I generally programmed 8080s using
> Zilog mnemonics because I preferred to. I have my druthers and you have
> yours. I enjoy talking about them --up to a point -- as long as no one
> seems to be proselytizing.
Proselytising? Maybe. I just happen to have
strong views on certain (Forth) things and,
as a buyer of Forths I see good reasons for
passing remarks, (in a forum such as this),
from the perspective of a buyer/user. Who
knows, some remarks might trigger thoughts.
I see application software as a work amplifier,
that is the only reason for it's existence and
the only reason for shelling out money for it.
The best work amplifier is one that can be driven
by a User who only has to think in terms of the
job being done. He should not have to spare any
mentals on the topics of; the vagaries of the OS,
the language used for writing the application,
the mental quirks of the programmer, and so on.
Difficult to achieve maybe, but not impossible.
I no longer buy (if poss) applications software
that requires too many mental gymnastics that are
not concerned with the application itself. And
an RPN assembler comes into that class, imo.
I don't know if you have seen AR's assembler for
the PIC, but it is in a class of its own. No RPN,
but with all the added Forth-type branching and
looping constructs. It makes MPASM look amateur.
As a buyer of Forths I would suggest that sellers
of Forths look carefully at AR's approach.
We'll just have to agree to disagree on this one
Jerry (again).
--
Tony Williams.
m_l...@my-deja.com
the addition posted in this message allows one to
use prefix notation with RPN assemblers.
Example: _( POP AX _ POP BX )_
instead of: AX POP BX POP
[END_BRIEFLY]
J Thomas wrote:
>
[prefix assemblers are not very Forth,
RPN assemblers are too exotic]
>
[..]
> I want it to do it both
> ways, whichever way I prefer at the moment.
[...]
There's a simple addition:
FORTH DEFINITIONS
\ ITC/DTC with multiple code fields ONLY !!!!
\ ?comp compiles only one word, the one next to it in the code!
: ?lit ( n -- ) \ compile a literal, if compilation
STATE @ IF [COMPILE] LITERAL THEN
;
: ?comp ( -- ) \ compile/execute the following (in the code) word
STATE @ IF R@ @ , R> 2+ >R THEN
;
ASM51 DEFINITIONS
VECT op
\ switching to prefix notation: _( POP AX _ POP BX )_
: _( ( "name" -- ) \ postpone execution of name
' ?lit
?comp {S: IS op
; IMMEDIATE
: )_ ( -- ) \ execute the postponed word
?comp op
['] NOOP ?lit
?comp IS op
; IMMEDIATE
: _ ( "имя" -- ) \ execute the postponed word,
\ postpone execution of a new word
?comp op
' ?lit
?comp IS op
; IMMEDIATE
FORTH DEFINITIONS
---
it seems, I translated all Russian text and removed all M: M' and {S: {S
Just in case, M: and M' are : and ' for meta-words.
{S {S: -- just ignore.
Andrew Haley
> In article <981648773.8903.0...@news.demon.co.uk>,
> Andrew Haley <a...@aph.demon.co.uk> wrote:
>> I always thought the great advantage of Reverse Polish assemblers
>> isn't how small they are but how well they fit into the language's
>> expression syntax.
>>
> I see an assembler as an application that happens
> to be written in Forth.
A separate standalone assembler, you mean? Sure, but that's a whole
'nother problem altogether. I'm talking about the integrated built-in
assembler. Y'know, the one that allows you freely to mix high level
code and assembly language, no linking, that kind of stuff.
However, if something is marketed as a standalone assembler it has to
function as one, and that will usually preclude RPN.
> There is no need for it to be Forthlike, far from it. The Reference
> Document is the uP mfr's datasheet and what is written in there is
> what the user should have to type, in the order given.
And thus are the laws of the Medes and Persians...
> Why impose another level of mental gymnastics to do?
Err, because conventional assembly languages are a thundering PITA?
> Why not let the computer do the mental gymnastics, that's what it
> was bought for.
The whole point of an integrated assembler is to reduce
mental gymnastics. If it doesn't do that it's *failed*.
Andrew.
Andrew Haley
> Jerry Avins <j...@ieee.org> wrote in message
> news:3A83193F...@ieee.org...
>>
>> What extra effort? When I'm switching back and Forth, It's easier to
>> stay in one mindset.
> The extra effort is when you have to translate the Intel documentation
> into RPN.
Ah, but that only happens while you're learning the processor; the
convenience of keeping in one mindset (does that make sense?) lasts
forever.
Andrew.
Jerry Avins
>
..
> looping constructs. It makes MPASM look amateur.
>
> As a buyer of Forths I would suggest that sellers
> of Forths look carefully at AR's approach.
>
> We'll just have to agree to disagree on this one
> Jerry (again).
>
> --
> Tony Williams.
We don't disagree here; we just have different tastes.
Gary Chanson
Andrew Haley <a...@aph.demon.co.uk> wrote in message
news:981717126.27990.1...@news.demon.co.uk...
I agree. Somehow, we seem to have gotten into an argument where both of
us are on the same side!
Stephen Pelc
<981648773.8903.0...@news.demon.co.uk>...
>I always thought the great advantage of Reverse Polish assemblers
>isn't how small they are but how well they fit into the language's
>expression syntax. To match a real manufacturer's assembler would
>require a full operator precedence parser; not very Forth.
Most of the forward assemblers I've seen or written in Forth do
not attempt to mimic the manufacturer's syntax completely. What
they do is to permit the opcode to come first, and then use a
space separated notation for the operands, e.g.
LDR r0, [ r3 # 55 ]
IMHO the most important reason for a prefix assembler is that
it is *much* more acceptable to people converting to Forth.
Since converting a postfix assembler to prefix involves about
ten lines of code and a little care, it isn't a big deal.
cLIeNUX user
>Andrew Haley wrote in message
><981648773.8903.0...@news.demon.co.uk>...
>>I always thought the great advantage of Reverse Polish assemblers
>>isn't how small they are but how well they fit into the language's
>>expression syntax. To match a real manufacturer's assembler would
>>require a full operator precedence parser; not very Forth.
>
>Most of the forward assemblers I've seen or written in Forth do
>not attempt to mimic the manufacturer's syntax completely. What
>they do is to permit the opcode to come first, and then use a
>space separated notation for the operands, e.g.
> LDR r0, [ r3 # 55 ]
>IMHO the most important reason for a prefix assembler is that
>it is *much* more acceptable to people converting to Forth.
>Since converting a postfix assembler to prefix involves about
>ten lines of code and a little care, it isn't a big deal.
Good a point as any to release an assembler I guess....
I'm writing a 386 assembler in Bash, the GNU sh-style unix-style command
interpreter. The unencumbered way-alpha version is
ftp://linux01.gwdg.de/pub/cLIeNUX/interim/shasm.tgz 42k
Not having seen any of your assemblers, it's gratifying to see that I'm on
the same track in some ways. shasm has two operand seperators, "to" and
"from". This generalizes out the Intel/AT&T source/dest/dest/source issue.
shasm tokens are shell command arguments. The opcode mnemonics are shell
routines, which are (unix) commands syntactically.
I liked the "asmacs" operator names I use so much that I noticed the m4
pass is extraneous if the assembler is in a command interpreter. One of
the reasons I'm releasing shasm to the public domain this early is because
others may not, and may want to substantially re-write shasm. shasm is
just at the point where the modR/M and SIB bytes look like they are almost
correct for the AND operator.
shasm operators have one or two operands. The only thing with positional
syntax within an operand's side of the to/from operand seperator is *2^,
the index shift specifier.
AND A *2^ 3 + C + 0x300 from DI
is
immediate value in EDI ANDed with the value in the memory location
pointed at by the contents of EAX upshifted 3 places, summed with the
the contents of ECX and 0x300.
I'm not even sure that's a real x86 mode, but that's the shasm syntax. The
"+"'s in this case are pure sugar, since the left side, the destination,
has already been disambiguated as a memory reference by the *2^ and the
fact that it involves two registers.
It takes shasm .03 seconds for one instruction like that on a p166. That
means it will take on the order of 2 minutes to assemble H3sm. It's about
100 times slower than gas, in round figures. Still quite useful for some
things. My primary motive for writing shasm is to maximize the portability
of H3sm. C is no more portable than assembly if your command interpreter
is an assembler.
Get shasm now if it interests you. I may pull it and/or bundle it with my
distro. Since it's shell script, I don't feel a whole lot of
responsibility to "maintain" it.
Rick Hohensee
www.clienux.com