Shop OBEX P1 Docs P2 Docs Learn Events
TACHYON O/S V3.0 JUNO - Furiously Fast Forth, FAT32+LAN+VGA+RS485+OBEX ROMS+FP+LMM+++ - Page 58 — Parallax Forums

TACHYON O/S V3.0 JUNO - Furiously Fast Forth, FAT32+LAN+VGA+RS485+OBEX ROMS+FP+LMM+++

15556586061109

Comments

  • MJBMJB Posts: 1,235
    edited 2014-11-10 10:20
    frida wrote: »
    A 1 step into 1-wire.
    I was looking after a 1-wire object, but couldn't find one.
    I saw something in the dropbox, but it was a mix of spin and forth.
    So I started my own development of a 1-wire in forth.
    Now I have it running and spitting 3 temperaturer back on me.
    I have had a lot of fun, and it is almost like assembler.
    Have a look at the object.
    It seeks the 1-wire and returns the id numbers of the chips with crc8 check.
    Then it send the temperature back on the console.
    Hi Frida,
    Peter also has a basic 1W.fth implementation, that I extended with ROM search.
    I didn't have time to do extensive testing and higher level functions.1W-MJB.fth.txt
    Will take a look at your code later.
  • jay-tjay-t Posts: 6
    edited 2014-11-10 11:25
    I now solved my problem: the BEGIN AGAIN loop didn't jump back to the BEGIN line.
    I putted the loop in a word with jimmyloop which calls the jimmy word with some cleaned up code.
    Now everything works and the robot can detect light and drive to a bright spot.

    I wrote a little code to detect light with this circuit: http://learn.parallax.com/activitybot/build-light-sensor-circuits
    LONG lightl
    LONG lightsensleft
    
    : lightleft 
        #8 HIGH
        #250 ms
        #8 LOW
        #8 PININP
        
        0 lightl ! 
        
        BEGIN
            lightl @ 1 + lightl !
            \ lightl @ . CR
            \ #8 PIN@ . CR
            #8 PIN@
            0=
        UNTIL 
        lightl @ lightsensleft !
        ;
    

    The light value is stored in lightsensleft after call. For the right sensor just use lightsensright as a name and then two sensors can be readed out!
    And set your pin number in the code. Higher counter numbers mean darker light and lower numbers brighter light.
    That is all.

    I use a senselight word which looks like this:
    : senselight
        BEGIN 
            lightleft
            lightright
        AGAIN
        ;
    

    It's called from the main program to run in another cog:
    ' senselight TASK? RUN
    

    So the robot can drive and measure light at the same time.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-11-10 15:46
    frida wrote: »
    A 1 step into 1-wire.
    I was looking after a 1-wire object, but couldn't find one.
    I saw something in the dropbox, but it was a mix of spin and forth.
    So I started my own development of a 1-wire in forth.
    Now I have it running and spitting 3 temperaturer back on me.
    I have had a lot of fun, and it is almost like assembler.
    Have a look at the object.
    It seeks the 1-wire and returns the id numbers of the chips with crc8 check.
    Then it send the temperature back on the console.

    Thanks for the contribution Frida, the 1wire search routines were started but weren't implemented at the time so this is a welcome addition.

    Just had a look at the DropBox file 1Wire.fth (and the webdoc) which was last updated 2 years ago not long after I had introduced Tachyon. The reason I looked was because you said it had a mix of "spin and forth" which just wouldn't be, which it isn't. But just having a quick look at your code it could be simplified somewhat, for instance just comparing the the 1wire reset word:

    You have:
    [FONT=courier new]pub OW_RESET ( -- t/f )
        ow_pin OUTPUTS \ ow_pin low
        #487 us \ ~500 us
        ow_pin INPUTS \ ow_pin high
        #66 us \ ~77 us
        ow_pin IN
        IF
            0 \ return false
        ELSE
            -1 \ return true
        THEN
        #487 us \ ~500 us
    ;
    [/FONT]
    

    The original does the same thing and is much simpler:
    [FONT=courier new]pub 1WRESET ( -- ack )    
        DQ@ OUTCLR 1 ms DQ@ INPUTS
         #80 us
         DQ@ IN 0=
         #400 us
         ;[/FONT]
    

    BTW, the use of the word OUTPUTS is more of a special operation and it is usually much better to use OUTSET or OUTCLR or similar as they set/clear the pin while ensuring it is an output without any extra overhead but IMO it helps us to see that the pin is cleared low. TRUE and FALSE are also the same thing as -1 and 0 if you want to convey the thought that it is returning a flag instead of a value.

    1wire devices cannot detect nor do they need precise timings so neither is there any need to try to overly trim timing in code and besides if it were important then the only real way to check timing is to measure it. The specification calls for a low pulse of 480us "minimum" so it doesn't matter if we use a 1ms or 100ms pulse to reset it and in fact it is better to add in a margin.

    The "us" word isn't perfect if you have very small values as there is overhead in the instruction itself as this test reveals:
    LAP 0 us LAP .LAP 3.800us ok
    0 LAP us LAP .LAP 2.800us ok
    LAP 10 us LAP .LAP 20.800us ok
    LAP 1 us LAP .LAP 10.600us ok
    LAP 100 us LAP .LAP 111.600us ok
    LAP 500 us LAP .LAP 512.200us ok

    I may revisit the delay words to see if I can trim their timing a bit but they have to do a multiply to calculate the number of waitcnts against the system clock. They look like this:
    : ms ?DUP 0EXIT 80,000 UM* DROP DELTA ;
    : us ?DUP 0EXIT 80 UM* DROP DELTA ;

    So it becomes more than redundant to say 0 us for instance as this operation will take 3.8us to accomplish nothing and 1 us still has to perform several operations to end up taking 10.6us doing it.

    Anyway, thanks again for the contribution, I think Brian Riley would be happy with that since he has a whole network of 1-wire devices. Seeing you are warmed up, we look forward to more :)
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-11-10 21:16
    jay-t wrote: »
    I wrote a little program for my mouse bot.
    The bot should search light with it's phototransistors. I did a run with motor driver battery unplugged:

    Propeller .:.:--TACHYON--:.:. Forth V24140928.1630
    Clock frequency = 80,000,000
    NAMES: $5B01...745E for 6493 (102 bytes added)
    CODE: $0000...3DBF for 9314 (577 bytes added)
    CALLS: 0420 vectors free
    RAM: 7490 bytes free


    jimmy light measure
    turn right
    driveahead
    driveahead
    driveahead
    ...

    It just repeats the "driveahead" message over and over again. Without jumping back to the BEGIN statement.


    It should print out the "light measure" message after "driveahead" by jumping back to "BEGIN", but it never does this.
    Maybe I messed up something with my IF/ELSE/THEN stuff?

    I just have no idea what is going on there.

    Sorry jay, missed this post somehow. I've just gone and refactored and reformatted your code so I can see (and you) what's going on. If you do this yourself when you write code it will be a lot easy to test, read, and modify. Keeping each word small and named appropriately and descriptively (not_that_descriptively_that_you_are_saying_whole_sentences_though) means that when you use the word elsewhere it should not even need a comment as the word DriveAhead already tells you what it's doing.

    I'm not sure if you need to do a -1 = IF as it looks like they are actual values and not flags and normally IF will accept any non-zero as a true but in this case it has to be at the maximum value of -1 or $FFFF_FFFF.

    You could also run jimmy in it's own cog with ' jimmy 6 RUN for instance (plus maybe some stack allocation) and that way you examine the sensors and variables from the serial console to see what is going on as well.

    However I don't see where "turned" is being cleared after you set it, that doesn't look right. I will continue to have a look at this code but this bit may be enough for you to debug the rest. Don't forget to post a little video or something later on if you can.
    [FONT=courier new]TACHYON
    
    : jimmybot.FTH            ." Jimmy the mouse bot main program " ;
    
    [~
    {
    The main control program for Jimmy the mouse bot.
    Refactored and reformatted - pbj
    }
    
    --- just make the motor control words fairly basic for clarity comapred to other actions
    ALIAS driveahead FORWARD
    ALIAS drivebackw REVERSE
    ALIAS drivestop HALT
    ALIAS turnleft LEFT
    ALIAS turnright RIGHT
    
        DECIMAL 
        LONG irleft,irright,irfront,turned
        LONG lightsensleft,lightsensright
    
    : TurnLeft
        ." turn left " CR
        HALT 1 second
        LEFT 1 second
        HALT
        ;    
    : TurnRightRev \ left side blocked, go backwards and right
        ." turn backwards right " CR
        HALT 1 second
        REVERSE 500 ms
        RIGHT 1 second
        HALT
        ;
    : TurnRight
        ." turn right " CR
        HALT 1 second
        RIGHT 1 second
        HALT
        ;
    : TurnLeftRev \ left side blocked, go backwards and left        
        ." turn backwards left " CR
        HALT 1 second
        REVERSE 500 ms
        LEFT 1 second 
        HALT
        ;
    
    : BackLeft
        ." backwards and left " CR
        HALT 1 second
        REVERSE 500 ms
        LEFT 1 second
        HALT
        turned ~~
        ;
    : BackRight
        ." backwards right " CR
        HALT 1 second
        REVERSE 500 ms
        RIGHT 1 second
        HALT
        turned ~~
        ;
    
    : DriveAhead
        ." driveahead " CR
        FORWARD 500 ms
        HALT
        ;
    : DriveBack \ no way to turn, drive backwards        
        ." backwards " CR
        HALT 1 second
        REVERSE 500 ms
        HALT
        ;
    : WhichWay?
        \ measure light on left and right side
        lightleft lightsensleft !
        lightright lightsensright !
        lightsensleft @ lightsensright @
        < IF \ left side is brighter, turn left
            irleft @ -1 = IF TurnLeft ELSE TurnRightRev THEN 
        ELSE \ right side is brighter, turn right
            irright @ -1 = IF TurnRight ELSE TurnLeftRev THEN 
        THEN 
        sensorfront irfront !            \ store sensor data
        irfront @ -1 = IF DriveAhead THEN    \ front free, drive ahead
        ;
    : Blocked!
        irfront @ irleft @ OR
        -1 = irleft @ -1 = AND IF BackLeft THEN 
        irfront @ irright @ OR
        -1 = irright @ -1 = AND IF BackRight THEN 
        turned @ 0= IF DriveBack THEN 
        ;
    : jimmy
        initpwm
        \ test IR LEDs
        tirfront tirleft tirright
        \ test motors
        FORWARD 500 ms
        REVERSE 500 ms
        \ beeperok
        5 seconds
        BEGIN
            sensorfront irfront !        \ store sensor data
            5 ms sensorleft irleft !
            5 ms sensorright irright !
            turned ~
            irfront @
            -1 = IF
                \ front free
                ." light measure " CR
                WhichWay?
            ELSE \ front blocked somewhere
                Blocked!
            THEN 
        AGAIN 
        ;
        
    ]~
    END
    [/FONT]
    
  • fridafrida Posts: 155
    edited 2014-11-11 01:44
    Well I must be blind, (maybe because I am old! :) ) but I can only find under MISC MODULES SpinOneWire.fth in your dropbox.
    But I got the webdoc file. Now I have something to study.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-11-11 02:09
    frida wrote: »
    Well I must be blind, (maybe because I am old! :) ) but I can only find under MISC MODULES SpinOneWire.fth in your dropbox.
    But I got the webdoc file. Now I have something to study.

    Yikes, that's a Spin file that got in there somehow and got renamed to a .fth file, how did that happen?? Oh well, time to clean up the folders I guess......

    I started looking at the SEARCH command at the time but it looked too messy plus I wasn't really using these 1-wire devices so that part got pushed to the bottom of the pile, until you came along and fixed it up.

    BTW, I've moved the "us" word to EXTEND and added in some compensation so after all the checks etc it's timing is good for 21us upwards but anything smaller will just cause it to exit early and still take around 11us. Only other way to get it better than that would be to make an opcode of it in the PASM kernel, but there's no room for that anyway.
  • Heater.Heater. Posts: 21,230
    edited 2014-11-11 07:11
    D.P.
    Heater's gonna go crazy...
    I am? Why? There is a lot of clever and innovative work going on in this thread. I have not participated here at all, though I see my name has come up here a few times.
    I can hear it now (WHAT ABOUT FFT)
    Well. I have not given up hope of casting my simple minded FFT into Forth one day. It won't be for Tachyon though. Perhaps gforth on my PC. Just so I get some idea how to work this language.
  • MJBMJB Posts: 1,235
    edited 2014-11-11 09:43
    Heater. wrote: »
    D.P.

    I am? Why? There is a lot of clever and innovative work going on in this thread. I have not participated here at all, though I see my name has come up here a few times.

    Well. I have not given up hope of casting my simple minded FFT into Forth one day. It won't be for Tachyon though. Perhaps gforth on my PC. Just so I get some idea how to work this language.
    If you really have a fast FFT in PASM, then why bother converting to a much slower FORTH.
    Then let's just make a PASM blop to load in a COG and feed it from Tachyon.
    If somebody needs fast FFT in Tachyon, then I think THAT's the way to go.
    Define a HUB array, put the data, give length + array-address to COG - check for sync - and be happy with the result in the defined HUB result array.
    Shouldn't be very difficult.
  • fridafrida Posts: 155
    edited 2014-11-11 10:39
    I am a beginner in forth. So first I spell it out line by line until I understand what is going on.
    When I understand it, then I can do 1 liners also.

    I have changed my OW_RESET a bit.

    old:
    pub OW_RESET ( -- t/f )
    	ow_pin OUTPUTS \ ow_pin low
    	#487 us \ ~500 us
    	ow_pin INPUTS \ ow_pin high
    	#66 us \ ~77 us
    	ow_pin IN
    	IF
    		0 \ return false
    	ELSE
    		-1 \ return true
    	THEN
    	#487 us \ ~500 us
    ;
    
    new:
    pub OW_RESET ( -- t/f )
    	ow_pin OUTPUTS \ ow_pin low
    	#487 us \ ~500 us
    	ow_pin INPUTS \ ow_pin high
    	#66 us \ ~77 us
    	ow_pin IN NOT
    	#487 us \ ~500 us
    ;
    
    I also changed:
    pub OW_WRITE_X ( 0|1 -- ) 
    	ow_pin OUTPUTS
    	NOP NOP NOP \ ~1.2 us
    	IF 	
    		ow_pin INPUTS
    	THEN
    	#49 us \ ~60.4 us
    	ow_pin INPUTS
    	NOP NOP NOP \ ~1.2 us
    ;
    
    and
    pub OW_READ_X ( -- 0|FF )
    	ow_pin OUTPUTS \ ow_pin low
    	NOP NOP NOP \ ~1.2 us
    	ow_pin INPUTS \ ow_pin high
    	NOP NOP NOP \ ~1.2 us
    \	1 us \ ~10.6 us \timing wrong with 4 elements on datastack
    \	0 us \ ~3.8 us -- ~4.2 us \ this works with more or nothing on datastack
    	ow_pin IN \ ow_pin read
    	#39 us \ ~50.6 us
    ;
    
    First I used 1 us, but it vent wrong with 4 data on the stack. Then I used 0 us, and it worked. After some test I now use NOP NOP NOP and get 1.2 us.

    I have done a lot of lap xx lap .LAP to find the right delay time. When I do lap 0 us lap .LAP I got 3.8 us with a empty stack, but when I do lap 0 us lap .LAP with 4 or more data on the stack I got 4.2 us.

    Now I can do CRC8 on the scratchpad registers also. Now I wil test on a long wire, to se if it still works.

    Have fun.
  • MJBMJB Posts: 1,235
    edited 2014-11-11 12:26
    Hi Frida,
    maybe you want to compare with this:1WireMJB-2014-11-11.fth.txt
  • Heater.Heater. Posts: 21,230
    edited 2014-11-11 14:05
    MJB
    If you really have a fast FFT in PASM, then why bother converting to a much slower FORTH. Then let's just make a PASM blop to load in a COG and feed it from Tachyon.
    Yes, but no, but yes, but...

    If I ever actually needed an FFT that was actually fast I would probably use somebody else's cleverer and faster code on a faster processor. All depends what the requirements might be.

    My rude and crude FFT was not about that. It was about solving a puzzle that had bugged me for a couple of decades or more. That is about how long it was between seeing my first FFT source code, in BASIC for the Atari 520, and starting to have even the slightest idea how it works. It was a deep mystery.

    Luckily, with input from this forum, I finally saw the light. The challenge then was to write my own FFT from scratch in C. Just to see if I could do it. And then to do that in Spin. And then to do that in PASM.

    By strange happen stance a couple of people here have made use of the resulting FFT on the Propeller.

    So it goes with the translation to Forth. It's about learning enough Forth to actually be able to make a simple program like that.

    It has been said here that I should not comment on Forth until I actually know what I'm talking about. Quite rightly so. So that is the challenge I have set myself, a significant, slightly complex piece of logic in Forth. Useful or not.

    I agree. If one wants a speedy FFT for Forth on the Propeller the PASM part of my FFT can be extracted and used as you describe. There is at least one other PASM FFT http://propeller.wikispaces.com/FFT. Perhaps an even faster option, I have never tried it.

    Some people spend hours on crossword puzzles or soduku or just watching TV. Me, I waste my time messing around with bits of code.

    My apologies for this little diversion to the Tachyon thread.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-11-11 17:00
    Heater. wrote: »
    MJB

    Yes, but no, but yes, but...

    If I ever actually needed an FFT that was actually fast I would probably use somebody else's cleverer and faster code on a faster processor. All depends what the requirements might be.

    My rude and crude FFT was not about that. It was about solving a puzzle that had bugged me for a couple of decades or more. That is about how long it was between seeing my first FFT source code, in BASIC for the Atari 520, and starting to have even the slightest idea how it works. It was a deep mystery.

    Luckily, with input from this forum, I finally saw the light. The challenge then was to write my own FFT from scratch in C. Just to see if I could do it. And then to do that in Spin. And then to do that in PASM.

    By strange happen stance a couple of people here have made use of the resulting FFT on the Propeller.

    So it goes with the translation to Forth. It's about learning enough Forth to actually be able to make a simple program like that.

    It has been said here that I should not comment on Forth until I actually know what I'm talking about. Quite rightly so. So that is the challenge I have set myself, a significant, slightly complex piece of logic in Forth. Useful or not.

    I agree. If one wants a speedy FFT for Forth on the Propeller the PASM part of my FFT can be extracted and used as you describe. There is at least one other PASM FFT http://propeller.wikispaces.com/FFT. Perhaps an even faster option, I have never tried it.

    Some people spend hours on crossword puzzles or soduku or just watching TV. Me, I waste my time messing around with bits of code.

    My apologies for this little diversion to the Tachyon thread.

    Wrangling with writing an efficient FFT in Forth? :) Not the kind of thing I would recommend for anyone to do for several reasons but it is certainly not the way to learn Forth. If you are very familiar and comfortable both with Forth and FFTs then you would be in a better position to see how you would shape Forth in such a way that made writing the FFT more natural and at the same time efficient. Unfortunately I think if you attempt to dive into the deep end of rough waters for your first lesson you may not dive again. Once bitten, twice shy, and the problem is the approach in the first place and what your motivation for doing it this way is.

    No, Forth was born out of a need for bare metal control (radio telescopes) with high level abstraction without losing anything in-between. The interactive shell/compiler is another layer that is a bonus as well. But when it comes to FFTs these things need to be compiled to the bare machine code to have any hope but this is not what Tachyon does, nor can it do much with the limited resources of the Prop itself. But it is possible to write an optimizing compiler in Tachyon that could reduce something like an FFT down to PASM which would then have to be loaded into it's own cog. Of course, writing the compiler would not really be worth the trouble unless it was running on an ARM where code space is not limited to 512 instructions, so therefore the FFT in PASM is all that is required.

    The way Frida is learning Tachyon Forth is a very good way as you can jump into small chunks of code and test them, even optimize them in different ways to get a feel for the merits of various approaches. So I would recommend that if you really want to play with your FFT that you incorporate your PASM version into Tachyon and perhaps even interface to the wave player to see if it's fast enough to do anything useful.
  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-11 18:04
    But it is possible to write an optimizing compiler in Tachyon that could reduce something like an FFT down to PASM which would then have to be loaded into it's own cog.
    I like this idea. It is the model that was used by Lisp programmers as well. You use Forth (Lisp) to craft a domain-specific language that makes it easy to talk about the things you're interested in. I think this is probably what you've already done with things like network stacks and HTTP request handling. FFT could be another example but one where you really want to generate machine code rather than just interpreted words. It would be really interesting to see an example of how this would be done.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-11-11 18:34
    David Betz wrote: »
    I like this idea. It is the model that was used by Lisp programmers as well. You use Forth (Lisp) to craft a domain-specific language that makes it easy to talk about the things you're interested in. I think this is probably what you've already done with things like network stacks and HTTP request handling. FFT could be another example but one where you really want to generate machine code rather than just interpreted words. It would be really interesting to see an example of how this would be done.

    I have written one-pass CPLD compilers in Forth that proved very compact, efficient, and flexible! It's the approach taken that makes a difference.

    An optimizing compiler would be better served operating on the source as a file, so a system with an SD card can take that source and perform multiple passes as required and generate the output files back to the SDFS. If this is the case then it is no trouble to implement any mix of infix as well as postfix notation and register addressing and it can still benefit from still being Forth in the use of "macros" etc. The compiler would be loaded as necessary and then "forgotten" after a compile with the binary available as a runtime object. This reminds me that I have to get a move on with my runtime object handlers as I already have the assembler anyway but an optimizing compiler to PASM would be a bonus. These runtime objects can be stored on file anywhere really, in a small system they would be in the upper 32K of a large EEPROM for instance, otherwise SDFS, or even SPI Flash which I plan to integrate transparently with the SDFS as a drive.
  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-11 18:40
    The compiler would be loaded as necessary and then "forgotten" after a compile with the binary available as a runtime object.
    How does "forget" work? I thought that the dictionary in Forth was organinzed like a stack and that "forget" just pops some definitions off the stack making the space formerly occupied by them available. Is that right? Is it also possible to forget things down further in the stack? I'm imagining that your compiler would produce additional dictionary words and so the compiler itself would not be on the top of the dictionary stack when the compilation was finished. How do you remove the compiler words but keep the compiler generated code? Or do I have this all wrong? :-)
    This reminds me that I have to get a move on with my runtime object handlers as I already have the assembler anyway but an optimizing compiler to PASM would be a bonus. These runtime objects can be stored on file anywhere really, in a small system they would be in the upper 32K of a large EEPROM for instance, otherwise SDFS, or even SPI Flash which I plan to integrate transparently with the SDFS as a drive.
    Are you talking about an optimizing compiler that would compile Tachyon Forth words into native PASM code? That would be cool!
  • Heater.Heater. Posts: 21,230
    edited 2014-11-11 23:05
    Peter,
    Wrangling with writing an efficient FFT in Forth? Not the kind of thing I would recommend for anyone to do for several reasons but it is certainly not the way to learn Forth.
    It seems I did not express myself clearly enough and the main point of my post was lost.

    I was trying to say that "efficient" is not the point of the exercise. "FFT" is not the point of the exercise. The point of my little goal is to learn enough Forth to be able to create some small but non-trivial function.

    I totally agree with you, as Braino has also pointed out, diving into something like an FFT is not a good way to start getting to grips with a new language. So that is not what is going on here. It's simply the "final exam" I have set myself for this course of study.

    Starting with baby steps. Whatever program I had in mind they all have the same fundamental needs: Data, variables, arrays, arithmetic operations, sequential statements, conditional statements, iteration constructs, sub functions and so on.

    If I ever master those simple concepts in Forth I'll then be trying to put it all together into something bigger.
  • MJBMJB Posts: 1,235
    edited 2014-11-13 01:02
    David Betz wrote: »
    How does "forget" work? I thought that the dictionary in Forth was organinzed like a stack and that "forget" just pops some definitions off the stack making the space formerly occupied by them available. Is that right?
    Hi David
    yes - that's basically it.
    There is another related option in pub vs. pri definitions, where the vectors of private words can be reclaimed, which makes theminvisible to later modules and reclaims some dictionar space and vectors.
    David Betz wrote: »
    Is it also possible to forget things down further in the stack?
    I'm imagining that your compiler would produce additional dictionary words and so the compiler itself would not be on the top of the dictionary stack when the compilation was finished. How do you remove the compiler words but keep the compiler generated code? Or do I have this all wrong? :-)
    that's why Peter was talking about 'batch' compilation reading the source from file and storing the output, the binary COG module, on file as well.
    think of compile <source >bin
    which loads in the compiler, runs the job and frees memory after.
    No words need to be created this way. maybe temp stuff, that can be removed, when unloading (forgetting) the loaded compiler module.
    then at later time the created module can be loaded from SD into a COG and run there.
    If there were more memory plus memory management (big RAM + GC ;-) ) then it can be done different as you were thinking, the LISP way.
    David Betz wrote: »
    Are you talking about an optimizing compiler that would compile Tachyon Forth words into native PASM code? That would be cool!
    sounds like it ... ;-)
    but I think a real first step into this direction is the assembler.

    Imagine:
    Heaters FFT PASM code slightly modified to match the special Tachyon-PASM syntax in it's file on SD.
    This is run through the Tachyon Assembler and creates a COG image on SD (kind of SD OBEX)
    Which now can be loaded into a COG and run whenever you like.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-11-13 04:05
    MJB wrote: »
    Hi David
    yes - that's basically it.
    There is another related option in pub vs. pri definitions, where the vectors of private words can be reclaimed, which makes theminvisible to later modules and reclaims some dictionar space and vectors.

    that's why Peter was talking about 'batch' compilation reading the source from file and storing the output, the binary COG module, on file as well.
    think of compile <source >bin
    which loads in the compiler, runs the job and frees memory after.
    No words need to be created this way. maybe temp stuff, that can be removed, when unloading (forgetting) the loaded compiler module.
    then at later time the created module can be loaded from SD into a COG and run there.
    If there were more memory plus memory management (big RAM + GC ;-) ) then it can be done different as you were thinking, the LISP way.

    sounds like it ... ;-)
    but I think a real first step into this direction is the assembler.

    Imagine:
    Heaters FFT PASM code slightly modified to match the special Tachyon-PASM syntax in it's file on SD.
    This is run through the Tachyon Assembler and creates a COG image on SD (kind of SD OBEX)
    Which now can be loaded into a COG and run whenever you like.

    Here's a color coded ASCII dump "memory map" which gives you a pretty good view of how memory is used in an almost fully loaded system with networking. The code grows up in memory while the dictionary grows down towards and I've used the same color for matching code and dictionary sections. This was done a few months ago before I implemented the SDWORDS which moves everything from the dictionary into the SDFS as an indexed rapid search, so all that dictionary memory you see is now free except for 1K plus whatever gets added afterwards.

    But here is a very quick memory map listing starting from low memory:

    0024 REGISTERS
    0124 VECTORS
    0929 KERNEL CODE
    1880 EXTEND CODE
    208A HARDWARE CODE
    2AA0 SDCARD CODE
    2F54 EASYFILE CODE
    3962 WIZNET CODE
    40A0 NETWORK CODE

    4E80 <FREE SPACE FOR APP>

    56A0 NETWORK WORDS
    xxxx WIZNET WORDS
    xxxx EASYFILE WORDS
    xxxx SDCARD WORDS
    xxxx HARDWARE WORDS
    xxxx EXTEND WORDS
    xxxx KERNEL WORDS
    7440 SOCKET BUFFERS
    7500 FILE BUFFERS
    7D00 RECEIVE BUFFERS
    7F60 CONSOLE STACK



    I have been thinking of implementing code addressing into virtual memory although I haven't run out of memory yet since I implemented SDWORDS, but later I may need it what with optimizing compilers and the like! It may even use a similar scheme to SDWORDS where I cache whole sectors of code that are read from an SDWORDS.TBC (Tachyon Byte Code) file. Normally this code would be like application code, it mostly references code in RAM with a smaller percentage of the application. So you could load up the optimizing compiler, run it, without having to "forget it" even though it's sitting in RAM, it is really in virtual memory in the SDWORDS.TBC file. So even the network servers and clients could be handled this way too, the few milliseconds to cache it is nothing. Just an idea but it sounds doable.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2014-11-13 09:29
    Peter,

    In case you haven't noticed, Tachyon is more popular than the Prop2 (measured in number of thread views). Compare:

    to your 145K views. :)

    -Phil
  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-13 10:42
    Peter,

    In case you haven't noticed, Tachyon is more popular than the Prop2 (measured in number of thread views). Compare:

    to your 145K views. :)

    -Phil
    Well, Tachyon actually exists. That might be one reason for it being more popular! :-)
  • Heater.Heater. Posts: 21,230
    edited 2014-11-13 11:26
    David,

    Hmmm...It's arguable if God exists. But the idea as always been really popular and written about a lot.

    But I know what you mean.
  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-13 11:28
    Heater. wrote: »
    David,

    Hmmm...It's arguable if God exists. But the idea as always been really popular and written about a lot.

    But I know what you mean.
    Are you saying that P2 is god? Or maybe that Chip is the god of P2? Aren't religious discussions banned from these forums? :-)
  • Heater.Heater. Posts: 21,230
    edited 2014-11-13 12:02
    David,

    No....My observation is that humans can believe in all kind of weird non-existent stuff: God, the devil, heaven, hell, capitalism, communism, society, punk rock, integers, e, PI, quantum mechanics, TV news, it's endless.... All figments of the human imagination that change a persons behaviour in many ways.

    Let's just say that "In Chip we trust".
  • David BetzDavid Betz Posts: 14,516
    edited 2014-11-13 12:27
    Heater. wrote: »
    David,

    No....My observation is that humans can believe in all kind of weird non-existent stuff: God, the devil, heaven, hell, capitalism, communism, society, punk rock, integers, e, PI, quantum mechanics, TV news, it's endless.... All figments of the human imagination that change a persons behaviour in many ways.

    Let's just say that "In Chip we trust".
    Sorry, I think I hijacked Peter's thread. Let's get back to talking about Tachyon which is much more interesting than all of this philosophical junk. :-)
  • Dave HeinDave Hein Posts: 6,347
    edited 2014-11-13 13:52
    In case you haven't noticed, Tachyon is more popular than the Prop2 (measured in number of thread views). Compare:

    to your 145K views. :)
    Phil, you're referring to the P2 thread that's only been around for 7 months. I think the previous P2 thread was around for a few years and had half a million views, or maybe it was only 300,000.
  • fridafrida Posts: 155
    edited 2014-11-22 03:31
    Propeller .:.:--TACHYON--:.:. Forth V24140928.1630
    Clock frequency = 80,000,000
    NAMES:  $5C89...745E for 6101 (3715 bytes added)
    CODE:   $0000...34EC for 7447 (7212 bytes added)
    CALLS:  0450 vectors free
    RAM:    10141 bytes free
    
    MODULES LOADED: 
    18C0: EXTEND.fth          Primary extensions to TACHYON kernel - 141027-1000
    BOOT: EXTEND.boot
    
    ----------------------------------------------------------------
    1 1 a  ok
    2 2 b  ok
    3 3 c --> C <-- not found 
      ok
    .S  Data Stack (6)
    $0000.0003 - 3
    $0000.0003 - 3
    $0000.0002 - 2
    $0000.0002 - 2
    $0000.0001 - 1
    $0000.0001 - 1
    $0000.0000 - 0 ok
    

    What are a and b doing?

    There is a fault in my 1 wire seek rotine, a new will follow soon.
  • MJBMJB Posts: 1,235
    edited 2014-11-22 04:23
    frida wrote: »
    Propeller .:.:--TACHYON--:.:. Forth V24140928.1630
    Clock frequency = 80,000,000
    NAMES:  $5C89...745E for 6101 (3715 bytes added)
    CODE:   $0000...34EC for 7447 (7212 bytes added)
    CALLS:  0450 vectors free
    RAM:    10141 bytes free
    
    MODULES LOADED: 
    18C0: EXTEND.fth          Primary extensions to TACHYON kernel - 141027-1000
    BOOT: EXTEND.boot
    
    ----------------------------------------------------------------
    1 1 a  ok
    2 2 b  ok
    3 3 c --> C <-- not found 
      ok
    .S  Data Stack (6)
    $0000.0003 - 3
    $0000.0003 - 3
    $0000.0002 - 2
    $0000.0002 - 2
    $0000.0001 - 1
    $0000.0001 - 1
    $0000.0000 - 0 ok
    

    What are a and b doing?

    There is a fault in my 1 wire seek rotine, a new will follow soon.
    Hi Frida,
    \ from EXTEND
    
    ( Select the desired target CTR A or B before use )
    pub A            ctr C~ ;
    pub B         1 ctr C! ; 
    
    
    A and B set the active counter.
    since a and b are not defined the input reader makes the word upper case and tries again.
    it finds A and B and does as commanded.
    since there is no "C" and "c" is not defined as well you get the error.
    The stack shows your 1 1 2 2 3 3 values

    so all is fine ;-)

    btw: 1-Wire - did you see the code that I postet? --- and my PM
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2014-11-22 18:14
    frida wrote: »

    What are a and b doing?

    There is a fault in my 1 wire seek rotine, a new will follow soon.

    As MJB pointed out "all is fine". In some Forths they are case insensitive which is mainly to cater to the C crowd I feel and so they accept lower case alphas in hex numbers. I could allow this I guess but what to make number processing more efficient especially during a large source code load I specify that all numbers must be recognizable in that they start with a valid decimal digit so DEADBEEF will not be recognized as a number. Instead with would prepend a 0 or a radix prefix such as $ or # or % to force it to be processed as a number. This latter method is preferred for all non-decimal numbers.

    In fact if you prefix a number it will preprocess it rather than scanning the dictionary for a match, failing, then trying to convert it as it normally would with a number. So my convention at present for source code is to set the default base to decimal and make sure all non-decimal numbers are prefixed.

    So the hex digit A would then be entered as $A or $0A or even 0Ah if you like. Because this preprocessor forces it to become a number it is quite flexible in what it will allow in the way of "separators", that's why you will see ports as #P26 for instance, because we can and it's so much clearer to see it's P26.


    I notice too that the .S routine is printing a dummy zero at the end of the list, this was a bug in an earlier version but if you recompile your system from current sources it will print clean.

    BTW, I appreciate the work you are putting into the 1-wire routines, especially the search function!
  • mklrobomklrobo Posts: 420
    edited 2014-11-23 03:05
    Are there any books and/or information on Tachyon Forth? I have tried used Spin, and it
    seems problematic.
  • fridafrida Posts: 155
    edited 2014-11-23 03:45
    I downloaded Tachyon V2.4.spin, and changed baud to 115200, but only get a blue screen like windoze.
    Unfortunately I deleted the old version before I tryed the new one.
    Tachyon V2.3.spin works, so now I have to start all over again.
Sign In or Register to comment.