Did you see my earlier post where I was using forward and backward labels plus symbols are nothing more than Forth variables and constants anyway. The thing is to make it appear more like the PC based assembler except with the advantages of self-hosting.
Yes, I saw a form of label, and some Forth symbol names.
It was not clear how far those reached, or if they were to a 'paste-able' level.
Well those labels are rudimentary of course but if you copied the code in the second listing and pasted or typed that into TF2 it would assemble as you go with only the first forward jmp not listing correctly (since it hasn't yet been resolved). The first code listing was a "cheat" in that I pasted once, forgot the definition, and pasted again which this time around it knew where to forward jump to to be able to list the hex codes for that jmp instruction.
If you get a look at the source (when you find it ) you will see that those labels are just constants, nice and simple. This does not preclude me from being able to do more abstract things later though. I can easily create symbol tables for any unknown words in a definition. Multipass will allow me more scope in all this.
Got it. You have been prolific enough on this, that I missed it. Thanks.
@jmg, it's nice to have some basic interactivity at this stage. Good for testing instructions and little bits of this and that.
Forth is a language and interactive environment all in one. If you haven't given it a go, I suggest you do. Very interesting experience, and quite unlike anything else that I've come across.
I have the TeraTerm terminal default set to 230400 baud with no character or line delays except for 2 stop bits since I haven't optimized the receive routine yet but it uses 60K for the buffer at present just because I can.
I haven't had any real success yet with running PNut under Wine *and* switching to the terminal, it seems to reset it or something and I haven't bothered yet to look into it. I am just using WinXP in Virtualbox on my LM17 system for development although I do run in seamless mode and have medit open in Linux.
Yes, I saw a form of label, and some Forth symbol names.
It was not clear how far those reached, or if they were to a 'paste-able' level.
Well those labels are rudimentary of course but if you copied the code in the second listing and pasted or typed that into TF2 it would assemble as you go with only the first forward jmp not listing correctly (since it hasn't yet been resolved). The first code listing was a "cheat" in that I pasted once, forgot the definition, and pasted again which this time around it knew where to forward jump to to be able to list the hex codes for that jmp instruction.
Yes, it is impressive - I was just thinking about paste from other assembler sources, which it seems very close to accepting.
One convention seems to be that the conditionals IF_xx are not in column 1, so maybe a label could be colum1-pivoted ?
(or, maybe you check the conditional keywords before deciding it is an asm label ?) Whichever is easiest ?
Yes, it is impressive - I was just thinking about paste from other assembler sources, which it seems very close to accepting.
One convention seems to be that the conditionals IF_xx are not in column 1, so maybe a label could be colum1-pivoted ?
(or, maybe you check the conditional keywords before deciding it is an asm label ?) Whichever is easiest ?
There is no set convention, I can place the if_cond at the end of the line if I want so exact position is not important. Bear in mind that I keep saying that this is the "raw" format, not the final format which is more PASM like that the preprocessor will handle before passing the raw format to Tachyon.
However I dislike the if_cond before the mnemonic as it messes up readability IMO and to me it looks better at the end of the line with any effects etc and I also have a shorthand version of those long conditionals such if_nc_and_nz becoming nc&nz etc.
It rained but I didn't get to play until now (almost 9PM)
SWEET!!!!! I didn't have TeraTerm on my little Windows laptop, so I decided to try puTTY (it used to be a pain point with any of the Forths) - the P2 sucked down the .fth files like crazy and everything works!! Now I just need to scrape the rust off my Tachyon and have at it!!
TeraTerm is great for Windows but make sure you grab the newer version and not the old versions. But TeraTerm maxes out at 921600 whereas Minicom will go as fast and faster than the FTDI part will go which is 3M.
I forgot that this version is setup for the big FPGAs in that I wasted a whole 64k on a receive buffer so what I will do is create a standard 115200 version with a smaller buffer that will run on a DE0-nano with 32k, unless of course someone else has configured Tachyon for this already (change rxsize and rxbuffers). Come to think of it the DE0 might only have a single cog so I will have to enable the simple receive for Tachyon until I can test an interrupt version.
I haven't used the Cordic engine yet because I know little about it but I took a hint from Seairth's tests and tried a Cordic multiply which produces a 64-bit result.
TF2# CODE QM
00.3637 FD03.1D8F qmul 1st , 2nd
00.363B FD63.1E18 getqx 2nd d
00.363F FD63.1C19 getqy 1st d
00.3643 FD60.002D ret
00.3647 end ok
TF2# ok
TF2# 12345678 DUP QM <D> . 152415765279684 ok
TF2# ok
TF2# ok
TF2# 12345678 DUP LAP QM LAP .LAP 112 cycles or 700ns @160MHZ ok
TF2#
I will have to play some more when I get some time, for now I am off to enjoy an Oktoberfest at a friend's place
TF2# ok
TF2# 12345678 DUP LAP QM LAP .LAP 112 cycles or 700ns @160MHZ ok
TF2#
For comparison, the 32 bit x 32 bit multiply for 64 bit result software routine I coded takes 206 cycles measured + time for 8 x pusha, a calla and reta with stack in HUB RAM. So I would think it's half the speed, plus the COG can't do anything else whilst it's calculating of course.
Are 1st and 2nd just aliases for tos and tos1, or will things like 328th also work? If they're just aliases, why don't you just use tos and tos1?
What's the "d" in "getqx 2nd d" and "getqy 1st d"?
It would be cool if you added a way to insert inline (runtime) forth in your inline assembly in your forth.
The assembler inserts an automatic s for source but here it needs a d for destination, but the assembler is still a work in progress. You can insert assembler right in the middle of forth code but I haven't tried it yet. EDIT: Just added a simple "' d assist !" to the end of this class's control like this:
pub OPC1 %1101011.000 OPC s ' d assist ! ;
So now you don't need the d at the end of the line
BTW, tos and tos1 etc are used internally in the kernel for PNut but I'm restricted with names in Tachyon so I choose less confusing terms 1st 2nd 3rd 4th which also corresponds to the high level 3RD and 4TH whereas DUP and OVER are the equivalent of 1ST and 2ND.
Also the assembler words are all in lower case as some have the same spelling as Forth words so I am using this as a simple way to distinguish the two vocabularies at present. Internally I have a 4-bit field in the header attributes which will identify the vocabulary at a later stage.
Edit: to qualify that statement about inserting assembly in Forth code is that this should work but actually it's not quite true because either you add it before the "call #colon" or do it Forth style and create a code word that is called from a Forth definition just like all the other "inline code" in Tachyon does it.
Even dropping a ORGH by itself to put in hub space does not work.
All attempts to set ORGH to addresses below $400 wil fail.
From what I see all hub references must be $400+
ie seems to not read Strings placed as ORGH data < $400
Come to think of it the DE0 might only have a single cog so I will have to enable the simple receive for Tachyon until I can test an interrupt version.
Chip stuffed two cogs into the DE0 Nano (by taking out cordic) so it ought to be a great platform for playing with TF2.
There's been so much happening on the forum lately that this "old" thread has been pushed into obscurity! Anyhows, I have been doing some work on TF2 but I have been updating the files in my regular Tachyon dropbox location in the P2 folder. Now when I dig up my DE0-Nano I like to give it a go on there too but I may have to have a slightly modified kernel that does not use the Cordic solver although I am keeping the memory map small at present.
I don't see any reason why I can't finish up the SD filesystem and test out the WIZnet network servers although I wanted to write the assembly level drivers in my P2 inline assembler. Even though that has been brought up to date it is in writing and testing these kinds of drivers that tests the mettle of the implementation. Let's see how it goes...
BTW, I've been using TeraTerm since I'm stuck inside the Windows virtual environment at present because of PNut and I just realized that even though I had set send delays to zero that there is an additional setting for copy&paste which was still set for 10ms. The download flew before but now it's even faster at 460.8k which seems to be as high as I can reliably go with TeraTerm. Once Chip has implemented the Flash bootloader I can probably work mostly with minicom in Linux and maybe find out why PNut doesn't play nicely with Wine.
Not having made any big progress in the past week I have instead been making many "little progresses" as I use TF2 to test out the P2 and fix up any bugs I come across or simply just add features. While I was playing with the SD routines I ran some tests and decided to not have any dedicated SD read and write routines, rather just generic SPI routines so that the SD block read becomes a simple and fast DO LOOP. So two words have been added that help to make these SPI block transfers fast, they are IC! and IC@ which are rather analogous to the sequence I C! and I C@ except that they do not push and pop the data stack but rather the IC@ expects a dummy stack value which it simple replaces while IC! leaves the data on the stack and also SPIRD and SPIWR leave/overwrite the value on the stack. This makes for a zippy loop so that the main SD block read and writes and just one line each.
While I am waiting for Chip to update the bootloader so we can backup and boot from SPI Flash I have been testing the various OS level features of Tachyon such as the SD FAT32 filesystem and the WIZnet W5500 Ethernet interface along with EASYNET servers etc. One of the decisions I made along the way is to further separate the DATA area from CODE which is also separate from NAMES. Most Forths however have the name as the header followed by the code field so a variable in typical Forths is composed of a link field,name field,code field, and parameter field where the parameter field is the data area. Not so with Tachyon as they all have their own areas in memory and in fact there is no link field either since one name follows another etc.
I'm happier about this since I am no longer trying to compile data structures in the code area. That means an overwrite won't corrupt the code but it also means that the data area can be initialized or backed up and restored easily. However VARIABLE still works the same old way but BYTE, WORD, LONG, BYTES, and LONGS now create constants that point to the data area where they have been allocated memory. The DATORG directive sets the origin.
--------------------------------------------------------------------------------
CODE MEMORY @ $00.6085 for 20,613
NAME MEMORY @ $00.B60E for 8,851
DATA MEMORY @ $00.E000 for 833
FREE MEMORY = 21,897
MODULES LOADED:
5173: EASYFILE.fth FAT32 Virtual Memory Access File System Layer V1.1 for TF2 151110-1430
49ED: SDCARD.fth P2 SD CARD Toolkit - 151108.0000
3B00: P2ASM.fth Tachyon Forth inline assembler for the P2 151022-0000
2940: EXTEND.fth TACHYON FORTH EXTENSIONS for the P2 - 151109-1240
-------------------------------------------------------------------------------- ok
Other than the generous receive buffer I have been keeping all these areas in the first 64k during development but obviously the code area is one that could benefit from its own area not that I am anywhere close to running out of room in the first 64k though. We have to leave room for video buffers etc.
Now the question I have been meaning to ask, is there anyone playing with the latest versions that I keep updated in my regular Tachyon Dropbox folder under the P2 directory?
I'm a few days behind. I need to load my DE2 with the latest FPGA and then grab the latest Tachyon2. Hopefully tomorrow since I'll be around my toys for a while.
I really wish my employer "officially" paid me to do this stuff!
The SD card routines are pretty zippy even for the 50MHz clock of the DE2-115 and even without smart pins. So I'm still playing with these devices and the kernel but I've also added some Explorer features to this so that I can check I/O and registers etc. I will have to have a look at the debug features of P2 too so that I can spy on other cogs.
So my configuration is the DE2-115 with the Parallax adaptor board, the one with the breadboard and the RCA DAC outputs. If you have got this I will publish some details on the SD card and W500 hookup (using the IoT5500 module) although I am still testing these interfaces at present.
TF2# lsio PORT PINS
+--------------------------+
P00 inp H ~ || H inp P63
P01 inp H ~ || H out P62
P02 inp H ~ || ~ H inp P61
P03 inp H ~ || ~ H inp P60
P04 inp H ~ || ~ H inp P59
P05 inp H ~ || ~ H inp P58
P06 inp H ~ || D L inp P57
P07 inp H ~ || D L inp P56
P08 inp H ~ || D L inp P55
P09 inp H ~ || D L inp P54
P10 inp H ~ || D L inp P53
P11 inp H ~ || D L inp P52
P12 inp H ~ || D L inp P51
P13 inp H ~ || D L inp P50
P14 inp H ~ || D L inp P49
P15 inp H ~ || D L inp P48
P16 inp H ~ || D L inp P47
P17 inp H ~ || D L inp P46
P18 inp H ~ || D L inp P45
P19 inp H ~ || D L inp P44
P20 inp H ~ || D L inp P43
P21 inp H ~ || D L inp P42
P22 inp H ~ || D L inp P41
P23 inp H ~ || D L inp P40
P24 inp H ~ || D L inp P39
P25 inp L ~ || D L inp P38
P26 inp H ~ || D L inp P37
P27 inp H ~ || D L inp P36
P28 inp H U || D L inp P35
P29 inp H U || D L inp P34
P30 inp H U || D L inp P33
P31 inp H U || D L inp P32
+--------------------------+ ok
TF2# lsregs COG #0 registers
$01F0: IJMP3 = $0000_0000
$01F1: IRET3 = $0000_0000
$01F2: IJMP2 = $0000_0000
$01F3: IRET2 = $0000_0000
$01F4: IJMP1 = $0000_0000
$01F5: IRET1 = $0000_0000
$01F6: ADRA = $0000_1180
$01F7: ADRB = $0000_0000
$01F8: PTRA = $0000_3B19
$01F9: PTRB = $0000_00B4
$01FA: DIRA = $1A00_0000
$01FB: DIRB = $7FFF_FFFF
$01FC: OUTA = $0800_0000
$01FD: OUTB = $4000_0000
$01FE: INA = $EDFF_FFFF
$01FF: INB = $C000_0000 ok
TF2#
While I am waiting for Chip to update the bootloader so we can backup and boot from SPI Flash I have been testing the various OS level features of Tachyon such as the SD FAT32 filesystem and the WIZnet W5500 Ethernet interface along with EASYNET servers etc......
.
.
.
Now the question I have been meaning to ask, is there anyone playing with the latest versions that I keep updated in my regular Tachyon Dropbox folder under the P2 directory?
I have a DE0 Nano that I played with early on with the first FPGA images ever released. I would join the party but I'm not sure there is a "build" that would support the bare Nano board (no daughter board) with a couple of cogs and Tachyon P2.
While I am waiting for Chip to update the bootloader so we can backup and boot from SPI Flash I have been testing the various OS level features of Tachyon such as the SD FAT32 filesystem and the WIZnet W5500 Ethernet interface along with EASYNET servers etc......
.
.
.
Now the question I have been meaning to ask, is there anyone playing with the latest versions that I keep updated in my regular Tachyon Dropbox folder under the P2 directory?
I have a DE0 Nano that I played with early on with the first FPGA images ever released. I would join the party but I'm not sure there is a "build" that would support the bare Nano board (no daughter board) with a couple of cogs and Tachyon P2.
Good news, Chip provides images for both a DE0 Nano and add on board, AND a DE0 Nano bare board (ie, no add on). The latter, which, incidently I am using. SO grab your DE0 and join the party.
I have a DE0 Nano that I played with early on with the first FPGA images ever released. I would join the party but I'm not sure there is a "build" that would support the bare Nano board (no daughter board) with a couple of cogs and Tachyon P2.
I take it you mean a build in terms of the Tachyon source, then you're right, the current build doesn't support the rather limited DE0 but if I find my DE0 somewhere I will create a version of the kernel to work on it and post it as the DE0 version as it is mainly the lack of Cordic instructions that's the main difference.
I have a DE0 Nano that I played with early on with the first FPGA images ever released. I would join the party but I'm not sure there is a "build" that would support the bare Nano board (no daughter board) with a couple of cogs and Tachyon P2.
I take it you mean a build in terms of the Tachyon source, then you're right, the current build doesn't support the rather limited DE0 but if I find my DE0 somewhere I will create a version of the kernel to work on it and post it as the DE0 version as it is mainly the lack of Cordic instructions that's the main difference.
Do you define the Cordic instructions in PNUT or with your inline assembler? Because if you define them with your inline assembler, maybe you could run a test for if the CORDIC is functional before defining CORDIC words, and then if the test fails, automatically define software fallbacks instead.
The kernel is compiled with PNut but it is possible to put runtime code in there to determine which 2K cog image to load I guess although a few functions are also hubexec. Anyway this is mainly for eval purposes on the DE0 so it isn't any real problem to have a kernel just for that at present since it's temporary.
Here is a dump of the screen when I first boot up Tachyon, load various modules until I get to the point where the SD filesys can load some modules directly from the SD card such as the networking modules. Scroll to the end to see the complete build.
TF2$ Cold start - no user code - setting defaults (0000.01A5)
Parallax Propeller 2 .:.:--TACHYON--:.:. Forth V10151109.1244 PIONEER
----------------------------------------------------------------
TF2$ IFDEF VOCAB: ok
TF2$ ok
TF2$ TACHYON 1 flags CLR Parallax Propeller 2 .:.:--TACHYON--:.:. Forth V10151109.1244 PIONEER
ok
0000 ok not found
0850
End of source code, 0300 lines processed and 0000 errors found
Load time = 323554186 cycles or @160MHZ 6.471sec
--------------------------------------------------------------------------------
CODE MEMORY @ $00.3F55 for 12,117
NAME MEMORY @ $00.C852 for 4,364
DATA MEMORY @ $00.E000 for 130
FREE MEMORY = 35,069
MODULES LOADED:
2A00: EXTEND.fth TACHYON FORTH EXTENSIONS for the P2 - 151109-1240
-------------------------------------------------------------------------------- ok
TF2# ok
TF2# BOOT ok
TF2# ok
TF2# ok
TF2# ok
TF2# ok
TF2# ok
TF2# TACHYON [~ Parallax Propeller 2 .:.:--TACHYON--:.:. Forth V10151109.1244 PIONEER
0485
End of source code, 0336 lines processed and 0000 errors found
Load time = 250755210 cycles or @160MHZ 5.15sec
--------------------------------------------------------------------------------
CODE MEMORY @ $00.4E4E for 15,950
NAME MEMORY @ $00.BDD0 for 7,054
DATA MEMORY @ $00.E000 for 151
FREE MEMORY = 28,546
MODULES LOADED:
3F55: P2ASM.fth Tachyon Forth inline assembler for the P2 151022-0000
2A00: EXTEND.fth TACHYON FORTH EXTENSIONS for the P2 - 151109-1240
-------------------------------------------------------------------------------- ok
TF2# ok
TF2# TACHYON [~ Parallax Propeller 2 .:.:--TACHYON--:.:. Forth V10151109.1244 PIONEER
0457 ok
0458 END
End of source code, 0511 lines processed and 0000 errors found
Load time = 220415978 cycles or @160MHZ 4.408sec
--------------------------------------------------------------------------------
CODE MEMORY @ $00.557A for 17,786
NAME MEMORY @ $00.BAB2 for 7,852
DATA MEMORY @ $00.E000 for 370
FREE MEMORY = 25,912
MODULES LOADED:
4E4E: SDCARD.fth P2 SD CARD Toolkit - 151108.0000
3F55: P2ASM.fth Tachyon Forth inline assembler for the P2 151022-0000
2A00: EXTEND.fth TACHYON FORTH EXTENSIONS for the P2 - 151109-1240
-------------------------------------------------------------------------------- ok
TF2# ok
TF2# ok
TF2# ok
TF2# ok
TF2# ok
TF2# ok
TF2# TACHYON [~ Parallax Propeller 2 .:.:--TACHYON--:.:. Forth V10151109.1244 PIONEER
0805 okot found
0806 END
End of source code, 0885 lines processed and 0000 errors found
Load time = 474473658 cycles or @160MHZ 9.489sec
--------------------------------------------------------------------------------
CODE MEMORY @ $00.6472 for 21,618
NAME MEMORY @ $00.B584 for 9,178
DATA MEMORY @ $00.E000 for 844
FREE MEMORY = 20,754
MODULES LOADED:
557A: EASYFILE.fth FAT32 Virtual Memory Access File System Layer V1.1 for TF2 151110-1430
4E4E: SDCARD.fth P2 SD CARD Toolkit - 151108.0000
3F55: P2ASM.fth Tachyon Forth inline assembler for the P2 151022-0000
2A00: EXTEND.fth TACHYON FORTH EXTENSIONS for the P2 - 151109-1240
-------------------------------------------------------------------------------- ok
TF2# ok
TF2# ok
TF2# MOUNT
Mounted 71CC.0203-F4D2.77F2 mkfs.fat WIDGET FAT32 3,965MB (4,096/cluster) ok
TF2# ls
WIDGET
P2ASM .FTH MENU .TXT MENU1 .TXT EASYNET .AVI FIRMWARE.ROM
EASYNET3.AVI EASYFILE.ROM EASYNET2.OGV HOME .HTM P8CPU .JPG
IOTPINS .JPG LOVE .WAV EXTEND .FTH P8 .H EASYNET .FTH
W5500 .FTH EASYFILE.FTH SDCARD .FTH IOT5500H.JPG DRAGON .JPG
IOT5500 .JPG 128K .BIN 256K .BIN W5200 .FTH WELCOME .TEL
WELCOME .FTP EASYNET .ROM POPCORN .WAV P8X32A .PDF IMAGE3
FRED .PNG FSRSCH .PNG FSRPCB .PNG IMAGE HTTP404 .HTM
IMAGE2 IMAGE1 LOGON .HTM TACHYON .HTM SITE0004.LOG
SITE0003.LOG SITE0002.LOG SITE0001.LOG FAVICON .ICO SYSLOG .TXT
HCB4208 .JPG CHARLCD .JPG ECOLCD .PDF LOVE .MP3 MENU2 .FTH
W5500TF2.FTH ok
TF2# FLOAD W5500TF2.FTH ok
TF2# TACHYON Parallax Propeller 2 .:.:--TACHYON--:.:. Forth V10151109.1244 PIONEER
ok
0501 okot found
0502 END
End of source code, 1058 lines processed and 0000 errors found
Load time = 302752362 cycles or @160MHZ 6.55sec
--------------------------------------------------------------------------------
CODE MEMORY @ $00.7115 for 24,853
NAME MEMORY @ $00.AFE3 for 10,619
DATA MEMORY @ $00.E355 for 128
FREE MEMORY = 16,078
MODULES LOADED:
6472: W5500.fth WIZNET W5500 driver for TF2 151110.1500
557A: EASYFILE.fth FAT32 Virtual Memory Access File System Layer V1.1 for TF2 151110-1430
4E4E: SDCARD.fth P2 SD CARD Toolkit - 151108.0000
3F55: P2ASM.fth Tachyon Forth inline assembler for the P2 151022-0000
2A00: EXTEND.fth TACHYON FORTH EXTENSIONS for the P2 - 151109-1240
-------------------------------------------------------------------------------- ok
TF2# ok
TF2# ok
TF2# FLOAD EASYNET.FTH ok
TF2# TACHYON [~ Parallax Propeller 2 .:.:--TACHYON--:.:. Forth V10151109.1244 PIONEER
0689 okot found
0690 END
End of source code, 1444 lines processed and 0000 errors found
Load time = 470131946 cycles or @160MHZ 9.402sec
--------------------------------------------------------------------------------
CODE MEMORY @ $00.8159 for 29,017
NAME MEMORY @ $00.AC37 for 11,559
DATA MEMORY @ $00.E355 for 304
FREE MEMORY = 10,974
MODULES LOADED:
7115: EASYNET.fth WIZNET NETWORK SERVERS 151111.0800
6472: W5500.fth WIZNET W5500 driver for TF2 151110.1500
557A: EASYFILE.fth FAT32 Virtual Memory Access File System Layer V1.1 for TF2 151110-1430
4E4E: SDCARD.fth P2 SD CARD Toolkit - 151108.0000
3F55: P2ASM.fth Tachyon Forth inline assembler for the P2 151022-0000
2A00: EXTEND.fth TACHYON FORTH EXTENSIONS for the P2 - 151109-1240
-------------------------------------------------------------------------------- ok
TF2#
I have a DE0 Nano that I played with early on with the first FPGA images ever released. I would join the party but I'm not sure there is a "build" that would support the bare Nano board (no daughter board) with a couple of cogs and Tachyon P2.
I take it you mean a build in terms of the Tachyon source, then you're right, the current build doesn't support the rather limited DE0 but if I find my DE0 somewhere I will create a version of the kernel to work on it and post it as the DE0 version as it is mainly the lack of Cordic instructions that's the main difference.
Well I needed instructions on getting the P2 image into the DE0 but I have that running now. Looking for a DE0 P2Tachyon Kernel
Comments
Well those labels are rudimentary of course but if you copied the code in the second listing and pasted or typed that into TF2 it would assemble as you go with only the first forward jmp not listing correctly (since it hasn't yet been resolved). The first code listing was a "cheat" in that I pasted once, forgot the definition, and pasted again which this time around it knew where to forward jump to to be able to list the hex codes for that jmp instruction.
If you get a look at the source (when you find it
@jmg, it's nice to have some basic interactivity at this stage. Good for testing instructions and little bits of this and that.
Forth is a language and interactive environment all in one. If you haven't given it a go, I suggest you do. Very interesting experience, and quite unlike anything else that I've come across.
I haven't had any real success yet with running PNut under Wine *and* switching to the terminal, it seems to reset it or something and I haven't bothered yet to look into it. I am just using WinXP in Virtualbox on my LM17 system for development although I do run in seamless mode and have medit open in Linux.
One convention seems to be that the conditionals IF_xx are not in column 1, so maybe a label could be colum1-pivoted ?
(or, maybe you check the conditional keywords before deciding it is an asm label ?) Whichever is easiest ?
There is no set convention, I can place the if_cond at the end of the line if I want so exact position is not important. Bear in mind that I keep saying that this is the "raw" format, not the final format which is more PASM like that the preprocessor will handle before passing the raw format to Tachyon.
However I dislike the if_cond before the mnemonic as it messes up readability IMO and to me it looks better at the end of the line with any effects etc and I also have a shorthand version of those long conditionals such if_nc_and_nz becoming nc&nz etc.
SWEET!!!!! I didn't have TeraTerm on my little Windows laptop, so I decided to try puTTY (it used to be a pain point with any of the Forths) - the P2 sucked down the .fth files like crazy and everything works!! Now I just need to scrape the rust off my Tachyon and have at it!!
Well done!!
I forgot that this version is setup for the big FPGAs in that I wasted a whole 64k on a receive buffer
I will have to play some more when I get some time, for now I am off to enjoy an Oktoberfest at a friend's place
What's the "d" in "getqx 2nd d" and "getqy 1st d"?
It would be cool if you added a way to insert inline (runtime) forth in your inline assembly in your forth.
For comparison, the 32 bit x 32 bit multiply for 64 bit result software routine I coded takes 206 cycles measured + time for 8 x pusha, a calla and reta with stack in HUB RAM. So I would think it's half the speed, plus the COG can't do anything else whilst it's calculating of course.
The assembler inserts an automatic s for source but here it needs a d for destination, but the assembler is still a work in progress. You can insert assembler right in the middle of forth code but I haven't tried it yet.
EDIT: Just added a simple "' d assist !" to the end of this class's control like this:
So now you don't need the d at the end of the line
BTW, tos and tos1 etc are used internally in the kernel for PNut but I'm restricted with names in Tachyon so I choose less confusing terms 1st 2nd 3rd 4th which also corresponds to the high level 3RD and 4TH whereas DUP and OVER are the equivalent of 1ST and 2ND.
Also the assembler words are all in lower case as some have the same spelling as Forth words so I am using this as a simple way to distinguish the two vocabularies at present. Internally I have a 4-bit field in the header attributes which will identify the vocabulary at a later stage.
Edit: to qualify that statement about inserting assembly in Forth code is that this should work but actually it's not quite true because either you add it before the "call #colon" or do it Forth style and create a code word that is called from a Forth definition just like all the other "inline code" in Tachyon does it.
Dropbox zip file have been updated.
http://forums.parallax.com/discussion/comment/1351134/#Comment_1351134
Even dropping a ORGH by itself to put in hub space does not work.
All attempts to set ORGH to addresses below $400 wil fail.
From what I see all hub references must be $400+
ie seems to not read Strings placed as ORGH data < $400
My resistance to buying a Propeller 1-2-3 FPGA board is weakening.
Forth really is useful for early adopters (it is interactive) and I am missing all the fun.
I don't see any reason why I can't finish up the SD filesystem and test out the WIZnet network servers although I wanted to write the assembly level drivers in my P2 inline assembler. Even though that has been brought up to date it is in writing and testing these kinds of drivers that tests the mettle of the implementation. Let's see how it goes...
BTW, I've been using TeraTerm since I'm stuck inside the Windows virtual environment at present because of PNut and I just realized that even though I had set send delays to zero that there is an additional setting for copy&paste which was still set for 10ms. The download flew before but now it's even faster at 460.8k which seems to be as high as I can reliably go with TeraTerm. Once Chip has implemented the Flash bootloader I can probably work mostly with minicom in Linux and maybe find out why PNut doesn't play nicely with Wine.
Compared to the code version of (SDRD). BTW, the assembler now automatically inserts whitespace around the # and , symbols etc.
This is the assembler output. Notice the whitespace that has been automatically inserted.
While I am waiting for Chip to update the bootloader so we can backup and boot from SPI Flash I have been testing the various OS level features of Tachyon such as the SD FAT32 filesystem and the WIZnet W5500 Ethernet interface along with EASYNET servers etc. One of the decisions I made along the way is to further separate the DATA area from CODE which is also separate from NAMES. Most Forths however have the name as the header followed by the code field so a variable in typical Forths is composed of a link field,name field,code field, and parameter field where the parameter field is the data area. Not so with Tachyon as they all have their own areas in memory and in fact there is no link field either since one name follows another etc.
I'm happier about this since I am no longer trying to compile data structures in the code area. That means an overwrite won't corrupt the code but it also means that the data area can be initialized or backed up and restored easily. However VARIABLE still works the same old way but BYTE, WORD, LONG, BYTES, and LONGS now create constants that point to the data area where they have been allocated memory. The DATORG directive sets the origin.
Other than the generous receive buffer I have been keeping all these areas in the first 64k during development but obviously the code area is one that could benefit from its own area not that I am anywhere close to running out of room in the first 64k though. We have to leave room for video buffers etc.
Now the question I have been meaning to ask, is there anyone playing with the latest versions that I keep updated in my regular Tachyon Dropbox folder under the P2 directory?
I really wish my employer "officially" paid me to do this stuff!
So my configuration is the DE2-115 with the Parallax adaptor board, the one with the breadboard and the RCA DAC outputs. If you have got this I will publish some details on the SD card and W500 hookup (using the IoT5500 module) although I am still testing these interfaces at present.
I have a DE0 Nano that I played with early on with the first FPGA images ever released. I would join the party but I'm not sure there is a "build" that would support the bare Nano board (no daughter board) with a couple of cogs and Tachyon P2.
Do you define the Cordic instructions in PNUT or with your inline assembler? Because if you define them with your inline assembler, maybe you could run a test for if the CORDIC is functional before defining CORDIC words, and then if the test fails, automatically define software fallbacks instead.
Here is a dump of the screen when I first boot up Tachyon, load various modules until I get to the point where the SD filesys can load some modules directly from the SD card such as the networking modules. Scroll to the end to see the complete build.
Well I needed instructions on getting the P2 image into the DE0 but I have that running now. Looking for a DE0 P2Tachyon Kernel