Critique of TransForth series

forth

    Sponsored Links

    Next

  • 1. handling pointers for 8051 processor
    Is there a consensus for handling pointers for the 8051 processor? You have idata and SFR overlap, and xdata starts at the same place with them, and with code. One way would be to take advantage of the third byte that sdcc uses to declare a pointer type, and add forth tokens to set it independently. thus: hex 81 set-pointer-type-sfr c@ would return the stack pointer. Another idea is to assign pseudo-addresses to each memory space and have the forth engine sort it out.
  • 2. Is there Optimized asm486.f for win32forth v4.2?
    Is there Optimized asm486.f for win32forth v4.2? win32for 4.2: code t 0xb8 c, 1 c, 0 c, 0 c, 0 c, next c; see t T IS CODE 366C4 B801000000 mov eax , # 1 ok code t1 mov eax, # 1 next c; ok see t1 T1 IS CODE 366DC C7C001000000 mov eax , # 1 ============================================= code y 0xb3 c, 3 c, next c; ok see y Y IS CODE 366F4 B303 mov bl , # 3 code y1 mov bl, # 3 next c; ok see y1 Y1 IS CODE 3671C C6C303 mov bl , # 3
  • 3. WHS MAIL ARRIVED
    Jack: Your present was received today. Thank you very much. I was glad to try and help resolve the problem, you didn't have to make a contribution but it is appreciated. Wish I had saved the original souce files, ah so:) Visit with wife's family on Christmas day. We had to travel about 180 miles each way. My current Son-In-Law did the driving which made the trip easier. Then today it was back to work. Cleaned up the office a bit and am expecting Randy Dumse in about an hour. Jack, again my thanks. Best Bill S.

Critique of TransForth series

Postby AshleyF » Thu, 10 Feb 2011 03:39:59 GMT

I've started a blog series building a Forth and would love to have
feedback/critical comments from {*filter*} Forth devs here.
 http://www.**--****.com/ 

The idea is to begin with the mechanics mainly in a high-level
language (F#) with regular data structures and a functional approach.
This way all the moving pieces can be seen easily. Then to slowly move
things to target a virtual machine with low-level, traditional
structures. Also to strip down to minimal primitives at that point.
Then finally target real hardware and play with it from there.

Re: Critique of TransForth series

Postby Hugh Aguilar » Thu, 10 Feb 2011 13:05:27 GMT



You might be interested in looking at STAAPL. This is a Forth written
in PLT-Scheme that targets the PIC18. There is at least some
similarity between F# and Scheme, in so much as they are both
functional languages. You and that guy might find some common ground.
I looked at his work a little and it was pretty interesting --- I
might have gotten involved if he had been targeting the PIC24 rather
than the PIC18.

For the most part, I doubt that many Forthers will be interested in a
Forth cross-compiler written in a language other than Forth. These are
the more common techniques:
1.) Write a cross-compiler for the target processor using a desktop
Forth system. Either use it to write applications, or use it to write
an on-board Forth system (an on-board Forth is more interactive and
easier to use).
2.) Write an on-board Forth system in assembly-language.
3.) Write a Forth *interpreter* in C (Gforth being an example).

I would recommend the #1 solution, but that is only because I know how
to write a cross-compiler (most Forthers don't). #2 is a lot of work.
#3 is a terrible idea, resulting in very slow execution speed --- this
is only for people who don't know assembly language.

I don't really recommend targeting a virtual machine (also known as a
"threaded Forth system") --- that is 1980s technology --- everybody
just generates machine-code now. I generated threaded code in MFX, but
that was only because I was targeting a Forth-engine that had hardware
support for running threaded code --- if you have to simulate the
virtual machine on a mainstream processor, it will be too slow.

Everybody seems to want to write a Forth compiler, but not very many
people are writing applications in Forth. If you do want to write
applications, see my novice package:
 http://www.**--****.com/ 
The world already has more than enough inefficient Forth
implementations written by hobbyists --- that is why I'm trying to
encourage people to write applications. If you want to write a Forth
system though, I will answer your questions as much as I can. I don't
know F# though, so I can't help with that.

Re: Critique of TransForth series

Postby Brad » Fri, 11 Feb 2011 00:37:30 GMT



Having built Forths in assembly, C, Forth and maybe VHDL, I think you
can have a lot of fun that way. But keep in mind that it won't
necessarily make you a better Forth programmer. Just as building a
bicycle isn't the same as learning to ride it, writing and using a
Forth are completely different activities.

Also, a Forth implementation encapsulates the experience of its
developers. Commercial implementations are the best (to at least
study), and contain many clever ideas not conveyed by the ANS
standard. There are many Forths written in C and some in Java.

So although I spent 20 years implementing Forths, I think you're
pissing in the wind.

-Brad

Re: Critique of TransForth series

Postby AshleyF » Fri, 11 Feb 2011 03:13:18 GMT

@Hugh I just spent an hour looking at Staapl. Looks very interesting
and right up my alley! Thanks for the pointer.

As for the approach, everything Ie learnt has been from 30 year old
books, so I certainly am applying 1980s technology :-) The idea is
mainly just to learn (and blog) about Forth. I planning to target a
VM just as a start then, within that working system, to write an
assembler and target native hardware. I guess most people would start
with an existing desktop Forth, but I want to appreciate the system
more by building it. Essentially trying to make a very minimal, albeit
slow, initial system with which to build something more practical.
Something like your #1 recommendation.

It very true that hardly any focus seems to be on writing apps.
Funny enough, the first thing I wanted to write in my Forth is a
LispKit SECD machine from Peter Henderson book just another
environment, still not an app! Maybe should do some games or something
fun instead. Or at least demonstrate some existing fun things working
(like Ian Osgood Forth implementation of the TSCP chess engine). I
very surprised (or maybe ignorant) that there no great repositories
of Forth library code. Your novice package is exactly the kind of
thing needed. Maybe there is plenty out there but so diluted by
bifurcation that it eelslike there is no central, de facto or
otherwise, standard library.

Re: Critique of TransForth series

Postby AshleyF » Fri, 11 Feb 2011 03:14:11 GMT

@Brad: Yep, I looking mainly to have fun and learn. Il take your
advice to heart and will need to not just build yet another Forth and
be done, but spend quality time writing apps and studying existing
commercial implementations. Thanks much for the advice! ... And I'm
sure in 20 years I'll fully agree with your last line :-)

Re: Critique of TransForth series

Postby Albert van der Horst » Sat, 12 Feb 2011 00:09:32 GMT

In article < XXXX@XXXXX.COM >,


<SNIP>

I was wondering about this pile up of misconceptions, until I saw
who the author is.
About 1. I had a comment here, but I deleted it. Instead I repeat


        "most forthers don't know how to write a cross=compiler"
        "Everybody seems to want to write a Forth compiler, but not
          very many people are writing applications in Forth."
So if a "forther" can't write a Forth system, and doesn't want to
write applications, what does a "forther" do? Ranting on c.l.f,
is that it?

About 2. I ported ciforth in an everning or two to 64 bits. (assembler).
That compares favorable to iforth (not, Marcel?). Maybe the size
and features of a Forth has something to do with it.

gforth an interpreter? gforth authors need not be expert assembler
programmers? You must be kidding.

<SNIP>

Groetjes Albert


Re: Critique of TransForth series

Postby Mat » Sat, 12 Feb 2011 06:08:06 GMT

Some remarks:

Forth systems written in C can be implemented platform independent
with gnu's label address extension, a feature which is also supported
from clang (llvm) and Intels compiler suite. Together with the
implementation of static superinstructions and some kind of
replication this results in very efficient interpretation comparable
in performance to interpretative systems written in assembler.

Simple native-code compiler for forth systems can be build with
minimal effort because Forth needs at minimum only very less
primitives and concatenate them together with some optimizations is
cheap but I predict the resulting performance gain against effective
interpretative systems is not worth the effort for most applications.

Re: Critique of TransForth series

Postby Hugh Aguilar » Sun, 13 Feb 2011 12:20:52 GMT

n Feb 10, 2:08m, Mat < XXXX@XXXXX.COM > wrote:

It may very well be that the performance of a Forth interpreter
written in C (typically a big SWITCH statement for the primitives, and
some other method of resolving the user-written functions) is
comparable to that of a Forth interpreter written in assembly-
language. In both cases, the performance is abysmal. Gforth is an
example of such a system written in C, and it is 2 to 3 times slower
than SwiftForth. Any language written in C is just a toy language ---
or a "scripting language" to use a more politically-correct term.
Gforth is like Lua, except without any features.


This is essentially what SwiftForth is doing. Functions are called
with a CALL instruction, so it is subroutine-threading. Also,
primitives get pasted into the code (what you describe as "concatenate
them together") with a very few peephole-optimizations done for
certain function-combinations that some genius at Forth Inc. decided
were common enough to be special-cased. There aren't enough of these
to have much of an effect on the performance though. Here is a typical
SwiftForth compilation:

icode init-list ( node -- node )
0 over ! ;

see init-node
46E98F 4 # EBP SUB 83ED04
46E992 EBX 0 [EBP] MOV 895D00
46E995 0 # EBX MOV BB00000000
; the above is the 0
46E99A 4 # EBP SUB 83ED04
46E99D EBX 0 [EBP] MOV 895D00
46E9A0 4 [EBP] EBX MOV 8B5D04
; the above is the OVER
46E9A3 0 [EBP] EAX MOV 8B4500
46E9A6 EAX 0 [EBX] MOV 8903
46E9A8 4 [EBP] EBX MOV 8B5D04
46E9AB 8 # EBP ADD 83C508
; the above is the !
46E9AE RET C3

This is horribly slow. All that has been accomplished is to get rid of
the CALL and RET instructions for each function, but there is no
optimization being done at all; the three primitives are just getting
concatenated together. SwiftForth code is not much faster than a
threaded system, but it is a lot bulkier. In the above we have 11
instructions just to set a variable to zero.

In my novice package, I have a lot of functions written in assembly-
language for SwiftForth. For example, here is the above (trimmed down
from 11 instructions to 2 instructions):

icode init-list ( node -- node )
eax eax xor
eax 0 [ebx] mov
ret

You would think that Elizabeth Rather would thank me for writing all
of this SwiftForth-specific assembly-language, but she hasn't.

SwiftForth code is horribly slow; it is endlessly adding and
subtracting constants to the EBP register, and moving data to and fro
between offset[EBP] and some register. SwiftForth is too slow to be
used for writing applications that do anything other than GUI. My
slide-rule program, for example, took long enough that the user could
go on a coffee break while he waited for the files to get generated.
Only after I introduced all of this assembly-language did I get the
speed into a reasonable range, so the user could just sit there and
watch without fidgeting. That program is working with linked lists of
up to 15000 elements, and several dozen text files, so it is not a
trivial program --- but it isn't complicated enough that you would
expect it to warrant assembly-language.

I think the reason why Elizabeth Rather tolerates Bernd Payson and
Anton Ertl, is becau

Re: Critique of TransForth series

Postby Hugh Aguilar » Sun, 13 Feb 2011 12:58:29 GMT

n Feb 9, 11:13m, AshleyF < XXXX@XXXXX.COM > wrote:

Writing a cross-compiler is a lot more difficult than writing a on-
board Forth system. As I said before, not very many Forthers know how
to write a cross-compiler, but any fool can write an on-board Forth
system (and most do!). Stephen Pelc is in the business of selling
Forth cross-compilers, and yet he doesn't know how to write a Forth
cross-compiler (he thinks that it is necessary to simulate the target
processor at compile-time for the defining words). I wrote a Forth
cross-compiler (MFX)for the MiniForth processor when I worked at
Testra, and it was a true Forth cross-compiler. I remember that I was
baffled as to how to do this, and so I went on long bicycle rides to
think on the subject. Then one night while riding my bicycle I had a
revelation as to how to do this, and after that cross-compilation
became easy. There is a fundamental aspect that has to be done
correctly, which is not obvious --- there is more to it than just
putting the host code in one word-list and the target code in another
word-list.

Tom's STAAPL is a pretty cool system. He isn't providing any defining
words though. If you want defining words, you have to write them in
Scheme rather than in Forth. That is not a bad system, especially if
you like Scheme, but it isn't a true Forth cross-compiler. I still
recommend that you study STAAPL and perhaps even contribute to STAAPL,
rather than write your own from scratch --- stand on Tom's shoulders,
you know.

You haven't said yet what target processor you are ultimately aiming
for. Is the PIC18 up your alley too? The PIC18 is somewhat obsolete,
as MicroChip has the PIC24 nowadays, but it is still a pretty good
micro-controller. There are PIC18 chips available that run at
significantly higher clock speeds than the PIC24, and that helps a
lot. I knew some guys in Golden who built their own HP41 calculator
based on the PIC18. They obtained the internal code for the HP41 from
HP and wrote a simulator in PIC18 assembly-language to run it, and
then built the calculator itself using off-the-shelf display and
buttons, all of which was housed inside of a transparent plastic case
that they built. It ran faster than the original HP41 calculator.
Computer programmers do some pretty crazy projects sometimes! It is
all good fun though.


Thanks for the compliment!

If you have any questions about the novice package, I'll answer them
as much as I can. Also, I would be interested in seeing any programs
that you write using the novice package as a basis --- I want to know
if there are short-comings that you had to work around, so I can
upgrade the code, or if there were aspects that you didn't understand,
so I can upgrade the documentation.

Re: Critique of TransForth series

Postby Alex McDonald » Sun, 13 Feb 2011 19:33:44 GMT



<snip>


How we've missed you! This one made me laugh like a drain.


Re: Critique of TransForth series

Postby Mat » Sun, 13 Feb 2011 21:34:01 GMT





Performance alone isn't a good viewpoint here because it doesn't
relate to effectiveness of implementation for a specific goal. If the
goal lays in highest possible performance achievable
with portability in mind, a effective C based interpreter can be a
good compromise.

On the other side, a simple native code compiler is not much work
either and porting it to different cpu architectures should be as
simple as it's implementation isn't to complex. In both ways
performance is not a problem as long as the underlying VM is in some
way extensible (though C functions for example). The Lua VM is one
example for this. Ficl is another. I think this extensibility together
with portability is the key point for an effective VM design (but
that's my own opinion of course).

Re: Critique of TransForth series

Postby Doug Hoffman » Sun, 13 Feb 2011 22:06:49 GMT




See:

 http://www.**--****.com/ 

-Doug


Re: Critique of TransForth series

Postby rickman » Mon, 14 Feb 2011 01:22:53 GMT






Both of you have broken the rule of replying.  But you are actually
responding as if this guy was mentally well.  You will not get much of
a rational response I can assure you.  In the process this litters the
group.

It is much better to just let it slide knowing that you are doing
everyone a favor.

Rick

Re: Critique of TransForth series

Postby Hugh Aguilar » Mon, 14 Feb 2011 06:04:24 GMT

n Feb 12, 5:34m, Mat < XXXX@XXXXX.COM > wrote:

C isn't any more portable than Forth, and is less so by most accounts.
It only seems more portable because somebody else has already done the
porting in most cases. Given a new processor though, and assuming that
nobody is volunteering to port either C or Forth to it, so the job is
up to you --- Forth would generally be the better choice. For example,
when Testra built their MiniForth processor, they could have built a C-
centric processor and ported GCC over to it. Instead, they built a
Forth-centric processor and hired me at $10/hour to write a Forth
cross-compiler or it --- which got the job done a lot sooner and at a
lot less money than if they had tried to port GCC.

Of course, if you are working with a mainstream processor, you can
assume that the legion of C enthusiasts has already ported GCC over to
it (or the processor manufacture has done so), and you are good to go.
There is no legion of Forth enthusiasts unfortunately. Also, as I
said, most Forthers don't know how to write a cross-compiler. Mostly
we just have people such as Alex McDonald laughing like a drain and
Rickman who calls me mentally ill because I said that vulgar
{*filter*} insults are inappropriate on comp.lang.forth --- but they
aren't writing any Forth code. As Ashley noticed, I'm pretty much the
only person around who is actually writing Forth code.

There are people writing on-board Forth compilers as a hobby.
Typically what you will get will be a slow threaded system --- and it
will be unmaintained because the author has since moved on to other
pursuits (such as driving a cab).


I'm learning Lua now. I don't really see Lua as being in the same
category as Forth though, because Lua is primarily for desktop C
applications that need an embedded scripting language to give the
users (who may have pretty minimal programming skills) access to the
internal data --- World of Warcraft being the killer app. By
comparison, Forth is used primarily in micro-controllers. The concept
of an embedded scripting language doesn't really make much sense in
that context.

As for FICL, it is only a subset of ANS-Forth --- it doesn't compile
my novice package. I contacted the author and he said that he has no
intention of upgrading FICL to the point where it would support my
novice package, and he suggested that I do the upgrade myself. I might
do that, but I'm not very enthusiastic because there is no particular
point to the exercise as I don't have any personal need for embedding
Forth in a C program --- I would be more likely to just use Lua, which
is being actively supported. FICL hasn't had an upgrade in so many
years that I thought it was dead --- then it recently did have an
upgrade, but it appears to be exactly what it was before, so this
upgrade may have just been a minor bug fix. FICL is still limited to
single-precision floats, which makes it pretty much useless for
generating gcode, which is the only application that I considered
using it for.

Re: Critique of TransForth series

Postby Albert van der Horst » Tue, 15 Feb 2011 13:07:44 GMT

In article < XXXX@XXXXX.COM >,


<SNIP>

Almost all languages in a Unix system have compilers written in C.
This much due to the fact that the Unix system itself is written in C.
As you know gcc stands for gnu compiler collection, and it is based
on C.
For all compilers you need to have knowledge of the
architecture of the target system but this is not to be confused
with assembler as a language.

Would you maintain that e.g. linux based algol68, FORTRAN, Pascal
or Python compilers are toy languages? ( Or better toy
implementations, as you cannot draw conclusions about a language based
on how one implementation.

<SNIP>

Groetjes Albert

Similar Threads:

1.Critique of TransForth series

2.series:series question

I started to have a look at series, and so far it seems very
interesting. One little question:

s-doc.txt says (series 'b 'c) => #Z(B C B C ...), but

S-TEST> (subseries (series 'a 'b) 0 10)
#Z(LIST A B LIST A B LIST A B LIST)

Could someone please explain to me, where the "LIST"s come from? Or
might this be a bug? Maybe I just don't get something...

Regards,

dhl


SBCL 1.0.6
series-2.2.9
Linux 2.6.21-ck

3.Code critique

 XXXX@XXXXX.COM  (Brian Harvey) writes:

> "Joe Marshall" < XXXX@XXXXX.COM > writes:
>>It turns out that eval is too powerful a construct.
>
> Interesting.  Does that mean we should stop saying "Languages should be
> designed, not by piling feature on top of feature, but by removing the
> restrictions that make additional features appear necessary"?

No, although I do think that this phrase should be taken with the
proverbial grain of salt.

> You seem to be staking out a class of "additional features" (in this case,
> macros) that aren't strictly necessary, but are preferable to the more
> general "removing restrictions" that eval provides for efficiency and
> program analysis reasons.

Let's remove the restrictions that make the whopper of an additional
feature called "eval" unnecessary...

Matthias

4.Application in Forth Critique

Sample code:
RAM/Flash socket adapter soft/hard emulator,
ECM bus probe capture and dashboard interface.
This Code Switches the interface between the PP and
a PLD simulation of the interface chip.
------------------------------------------------------------------------
\\ ECM.4th

\ rev  date       description
\ 001  20050630   Converted from ADP-IO.4TH with PP interface
\ 002  20050729   VCC Detection, swaped keys in SHOW-VAR,
\                 GET-MPS & GET-TPS new codes, GET-XX1 changed to GET-SPK
\                 GET-SPK included in LOG
\ 03   20060708   Changed auto increment so it can be used by trigger
\ 04   20060709   Combines GET-VAR & CAP-VAR added item GET:TIC
\ 05   20060710   Added double fetch to SV
\ 06   20070704   PLD simulator finished
\ 07   20070707   Trg-ads_trg-dat_dat-ads moved to PLD
\ 09   20071111   RS232 interface added.
\ 11   20080101   PCB layout.

1 .IF \ Set false to reload with out changing the CAP_BUF

I80387

EXISTS? ECM_4TH
.IF     FORGET ECM_4TH
.ELSE
: LD  INCLUDE ECM.4TH ;
.THEN

: ECM_4TH ;

1 EQU SIM.M

SIM.M
.IF
: ED  ( -- )  SHELL" ME ECM.4TH ECM-ANA.4TH C:\PLDS\ECM-SIO\ECM-SIM.4TH 
C:\PLDS\ECM\ECMADP.DOC" ;
.ELSE
.THEN
: EDV ( -- )  SHELL" ME VARS-000.TXT" ;
: EDL ( -- )  SHELL" ME *.LOG" ;
: EDT ( -- )  SHELL" ME *.TXT" ;
: ISP ( -- )  SHELL" EXP16.EXE ECMADP.DLD" ;
: NC  ( -- )  SHELL" NC" ;
DECIMAL

ASM
INCLUDE \4THS\EXTENDS\ASM_SYN.4TH

NTFORTH?
.IF
INCLUDE \4THS\EXTENDS\NTTIMERS.4TH
INCLUDE \4THS\EXTENDS\NTASYNC.4TH
.ELSE
INCLUDE \4THS\EXTENDS\MTIMER.4TH
INCLUDE \4THS\EXTENDS\UTIMER.4TH
.THEN


VARIABLE TCTR
VARIABLE MCTR
VARIABLE LCTR

10000 ITEM WAIT:TIME \ uS
  200 ITEM CAP:TIME  \ mS   100
  200 ITEM TRG:TIME  \ mS
  200 ITEM REF:TIME  \ mS
  200 ITEM DAT:TIME  \ mS   320
    0 ITEM CAP:TIC   \ CAP-VAR mS !
    0 ITEM DAP:TIC   \ CAP-2VAR mS !
    0 ITEM TRG:TIC   \ WAIT-TRG mS !
    0 ITEM XAD
    0 ITEM ADS
    0 ITEM EV:CMD
  100 ITEM MAX:DIF  \ uS
    1 ITEM CR:FLG
    0 ITEM EV:REF
    0 ITEM VCC:FLG
    0 ITEM LOG:ON
10000 ITEM LOG:TIME

  3274 ITEM T:ADS \ 3061
   213 ITEM T:DAT \  247
                  \  D0
                  \ 142  14200 mS trigger loop
DECIMAL
: WAITS  ( sec -- )
   0
   DO  1000 MSEC-SLEEP
      KEY? IF LEAVE THEN
   LOOP
;
   0 ITEM SEED
: random ( -- n )                             \ 0 <= n <= 32767
   SEED 259 * 3 + 32767 AND
   DUP TO SEED
;
: RANDOM ( n1 -- n2 )                            \ 0 <= n2 < n1
   random M* 32768 UM/MOD NIP
;

( BASE: ) HEX

378 ITEM LPT:BASE
0FF ITEM LPT:DATA

: !LPT-DATA ( c -- ) LOBYTE DUP LPT:BASE PC! TO LPT:DATA ;
: @LPT-STS  ( -- c ) LPT:BASE 1+ PC@ ;


01 EQU LPTD.SDI \ Serial data to chip    ISP pin 6  Direction
02 EQU LPTD.CLK \ Clock                  ISP pin 1  Step
04 EQU LPTD.MOD \ Mode                   ISP pin 3  Enable
08 EQU LPTD.ISP \ ISP, active low        ISP pin 5  ISP
10 EQU LPTD.RST \ RST, active low        ISP pin 5  Reset
20 EQU LPTD.JTG \ JTG, active high       ISP pin 5  Reset

40 EQU LPTS.SDO \ Serial data from chip  ISP pin 7
08 EQU LPTS.VCC \ VCC    data from chip  ISP pin ?

: LPTD-SET   ( m -- )        LPT:DATA OR  !LPT-DATA ;
: LPTD-CLEAR ( m -- ) INVERT LPT:DATA AND !LPT-DATA ;

:M SDI-LOW  ( -- ) LPTD.SDI LPTD-CLEAR M;
:M SDI-HIGH ( -- ) LPTD.SDI LPTD-SET   M;

:M CLK-LOW  ( -- ) LPTD.CLK LPTD-CLEAR M;
:M CLK-HIGH ( -- ) LPTD.CLK LPTD-SET   M;

:M MOD-LOW  ( -- ) LPTD.MOD LPTD-CLEAR M;
:M MOD-HIGH ( -- ) LPTD.MOD LPTD-SET   M;

:M ISP-LOW  ( -- ) LPTD.ISP LPTD-CLEAR M;
:M ISP-HIGH ( -- ) LPTD.ISP LPTD-SET   M;

:M JTG-LOW  ( -- ) LPTD.JTG LPTD-CLEAR M;
:M JTG-HIGH ( -- ) LPTD.JTG LPTD-SET   M;

:M RST-LOW  ( -- ) LPTD.RST LPTD-CLEAR M;
:M RST-HIGH ( -- ) LPTD.RST LPTD-SET   M;

0 ITEM DBG:FLG
0 ITEM SDO_CTR

SIM.M
.IF  \ Simulation Mode

0 ITEM  POW:FLG
0000 EQU ADS.MASK

INCLUDE \PLDS\ECM-SIO\ECM-SIM.4TH
   HEX  INIT-SIM

: DBG-ON  ( -- )   1 TO DBG:FLG 0 TO ITER
   >FILE DBG.LOG .T CR CONSOLE
;
: DBG-OFF ( -- )   0 TO DBG:FLG
   >>FILE DBG.LOG .T CONSOLE
;

: DEBUG ( - - )
    >>FILE DBG.LOG
    ITER 14 MOD 0= IF .HDR THEN ITER .STATE
    CONSOLE
;
: !CLK ( f -- ) 0= 1 AND >>IO %SCK  ECM-SIM
    DBG:FLG  IF DEBUG THEN
;
: !SDI ( f -- )    1 AND >>IO %SDI  ECM-SIM ;
: !MOD ( f -- ) 0= 1 AND >>IO %MODE ECM-SIM ;

: @SDO ( -- f )    %SDO  ECM-SIM
    DBG:FLG  IF DEBUG THEN
;
: @STS ( - - sts )
   %SDO    0= 0= LPTS.SDO AND
   POW:FLG 0= 0= LPTS.VCC AND OR
;
.ELSE \ ECM Mode

2AAA EQU FLASH.UAA  ( Unlock address AA )
5555 EQU FLASH.U55  ( Unlock address 55 )
7000 EQU ADS.MASK

: SDO-CTR  ( -- )
    SDO_CTR 1 > IF SDO_CTR 1 .R THEN  0 TO SDO_CTR
;
: !SDI ( f -- )
\               DBG:FLG IF SDO-CTR  DUP IF ." D" ELSE ." d" THEN THEN
                IF SDI-HIGH EXIT THEN SDI-LOW ;
: !CLK ( f -- )
\               DBG:FLG IF SDO-CTR  DUP IF ." C" ELSE ." c" THEN THEN
                IF CLK-HIGH EXIT THEN CLK-LOW ;
: !MOD ( f -- ) IF MOD-HIGH EXIT THEN MOD-LOW ;
: !ISP ( f -- ) IF ISP-HIGH EXIT THEN ISP-LOW ;
: !JTG ( f -- ) IF JTG-HIGH EXIT THEN JTG-LOW ;
: !RST ( f -- ) IF RST-HIGH EXIT THEN RST-LOW ;
: @STS ( -- c )  LPT:BASE 1+ PC@ ;


: @SDO ( -- f ) @STS LPTS.SDO AND 0<> 1 AND
\    DBG:FLG
     IF      SDO_CTR 0=
       IF    DUP IF ." O" ELSE ." o" THEN
       THEN  SDO_CTR 1+ TO SDO_CTR
     THEN
;
.THEN \ End of Simulation/ECM Modes

: @VCC ( -- f )
     @STS  LPTS.VCC AND 0<> 1 AND
;

5.associating a symbol to a list and a string : script critique requested

6. A Critique of Common Lisp

7. a tuple critique

8. Code critique (was equality tester)



Return to forth

 

Who is online

Users browsing this forum: No registered users and 90 guest