That's fine for an erase as I looked at that first but sometimes this is a general fill which would have to end up being a WRBYTE so that we could write the immediate D field. I am not sure about SETQ, does it increment the D field or only the S field in a WRxxxx? If the D field is not touched then I could use WRLONG etc.
That's fine for an erase as I looked at that first but sometimes this is a general fill which would have to end up being a WRBYTE so that we could write the immediate D field. I am not sure about SETQ, does it increment the D field or only the S field in a WRxxxx? If the D field is not touched then I could use WRLONG etc.
BTW, thanks for the tip too.
I imagine you mean ALTDS, not SETQ here.
ALTDS could be used to set an immediate D. It just substitutes the D field bits.
Yes, I did try a long fill and it works well but byte/word/long are normally decided at runtime due to the wide range of parameters that will be thrown at it.
It's always a size/speed trade off...
This is small enough, you may be able to just have versions for Byte/Word/Long and if users want speed, they choose 32b aligned data ?
Most would understand that.
That may not be larger than the housekeeping needed for a long/byte split speed up.
I noticed that there is a Winbond 25Q80 on the DE2-115 add-on board which I guess is used for P2 boot when it's available. In the meantime I'm looking at using this for some temporary backup to hold source code files and binary images.
Are these the right pins for the chip?
In the meantime I will start writing some code to access the chip after which I may bundle it in the PNut compiled kernel itself so that it is ready to load from there. I see that there is an SD card socket on the DE2, is that accessible from the P2? I could probably get the SD card up and running faster than the serial Flash and it's more useful. If it's not accessible I may just add one.
Seems that the REV instruction has somehow mixed it's source and destination or something. In P1 it definitely worked in Tachyon with the code:
rev tos1,tos
where tos1 was the value that had to be reversed by tos bits but in the P2 this doesn't work where I want to:
TF2$ 7 #24 REV .LONG 1800.0000 ok
in the P1 with the exact same code I get:
7 #24 REV .LONG 0000.00E0 ok
and
$86 #24 REV .LONG 0000.0061 ok
Checking the P2 code:
TF2$ ' REV COG@ .LONG F993.2591 ok
TF2$ ' REV COG@ DUP $1FF AND .WORD 0191 ok
TF2$ DUP 9 SHR $1FF AND .WORD 0192 ok
TF2$ DUP #19 SHR $1FF AND .WORD 0132 ok
TF2$ DUP #19 SHR $1FF AND BINARY ok
TF2% . 100110010 ok
TF2% DUP #28 SHR .BYTE 0F ok
TF2% HEX ok
So S and D are correct except for the I field which according to the instructions is %100110001 so it looks like an assembler bug.
Nope, that must have been a typo on my part, I've checked and it is %100110010 (ICZ) so that's correct. But REV is not working as it should.
TF2% ' REV 2 COGLIST
0057: 1111 100110010 R 0192,0191
0058: 1111 110110011 I 01FF,0104 ok
TF2%
BTW, I found a bug with SUBX too, is there one place where we can report these bugs or observations.
BTW, I found a bug with SUBX too, is there one place where we can report these bugs or observations.
Just start a new thread on the topic. That way, we all see it, can help verify/troubleshoot, and make sure that follow-up comments don't get buried in another thread (like this one).
Just interfaced the W25Q80 serial Flash that is on the DE2-115 add-on board and it seems to work well. I can read and write large blocks with ease.
Now on to the next step of interfacing to the SD card which I will have to hook-up probably to the same pins as the serial Flash except I will give the SD card its chip select on P57.
Now if that all works then the next step is the W5500 module for some P2 networking!
As mentioned I have the W25Q80 serial Flash working nicely. Just before I proceed with the SD card interface I added a couple of extra functions for the serial Flash. First is that I made my DUMP words able to read any kind of memory that I specify rather than just hub RAM. Secondly I added a general BACKUP command which if I configure the kernel correctly will allow me to choose images to load. I will probably leave source code load to the SD card as it is easier to place large files on there from the PC.
Here I erase a 64k chunk at address 0 for the test, dump it using SF to modify DUMPs behaviour, check RAM at the same address, backup and check and also check 256k boundary in serial Flash.
It lived!!! Great work, as always, Peter!! You and the P2 sure are productive together!
I can't wait until we can all play Tachyon2
Oh, I haven't bothered releasing it because I didn't think anybody could be bothered! ( what with all the debates which are far more "interesting")
But I will add a couple of extras now before I put it out there, that is, if anybody wants to play.
In view of the fact that we need to know more about the opcodes and how they work I've decided to proceed with my inline assembler so that I can quickly create routines and test them from the Forth console as it is quite easy to throw sequential and random data at it and examine the results in various formats suited to the task.
I have a simple infix mode so that I can enter the assembly code in the same fashion as we would for PNut but it also generates a listing, both as hex and also as bit fields. So this might take me a day or two to get all the opcodes entered and addressing modes sorted out but the other benefit of this is that I can then start writing assembly language drivers for Tachyon in Tachyon itself.
Here's the skeleton of my assembler in just a few lines:
{ TF2 P2 ASSEMBLER
TF2 ASM format is the same as PASM
if_z ROR tos1,tos wc,wz
}
long opcocde
pub EFF! MASK opcode SET ;
pub wc #20 EFF! ;
pub wz #19 EFF! ;
pub # #18 EFF! ;
pub CC! #28 SHL opcode @ $0FFF.FFFFF AND OR opcode ! ;
pub if_c %1100 CC! ;
pub if_z %1010 CC! ;
pub always %1111 CC! ;
\ Write opcode 7+3-bit opcode field and set default conditions etc
pub OPC! #18 SHL opcode ! always ;
pub ROR %0000000.000 OPC! ;
pub ROL %0000001.000 OPC! ;
pub SHR %0000010.000 OPC! ;
The infix mode simply defers some actions until the end of the line while allowing commas and other lack of whitespace, So there is no special syntax unless I really enforce it so all kinds of "macros" are possible too.
Just for the curious this is a simple interactive assembly listing I get as I type in assembly in its "raw" format, before I introduce the infix preprocessor. This is not actually compiling the object code to memory at the moment, just listing it.
In here I compare the result with what should be the equivalent in the Tachyon kernel. Then I decide I'd like a "macro", so I make one to help with that too.
ASM
00.287E F107.2001 ADD tos d # 1 s
00.287E 0000.0000 ' 1+ COG@ SPACE .LONG F107.2001
00.287E F067.2001 SHL tos d # 1 s
00.287E 0000.0000 ' 2* COG@ SPACE .LONG F067.2001
00.287E 0000.0000 : see [COMPILE] ' [COMPILE] GRAB 4 ADO SPACE I COG@ .LONG LOOP ; IMMEDIATE
00.287E 0000.0000 see 2* F067.2001 FD60.002D F993.2390 FD9F.FF04
00.287E 0000.0000 see 1+ F107.2001 FD60.002D F047.201F F9E7.21DC
The infix mode simply defers some actions until the end of the line while allowing commas and other lack of whitespace, So there is no special syntax unless I really enforce it so all kinds of "macros" are possible too.
I still haven't finished this inline assembler as I made some additions to the Tachyon kernel in the meantime including buffered serial receive so I could load source at maximum speed. Before this I wasn't too concerned, I just needed functionality.
Well I'm still entering the opcodes and along the way I am testing what I have and what I need to do which may include some extra class information with the opcodes too. The preprocessor will come last but in the meantime it's quite interesting how you can mix your directives and operands around like this:
I don't expect this to be bug free at present as the -4 in the djnz corrupted the opcode etc. But I do like the fact that the conditional execution directives such as if_c can be placed at the end of the line.
Just seen Seairth's post about these instructions, so I will have to play with that too.
02.003C FDB4.001A call # ' DROP wc
02.0040 FD60.002D ret
02.0044 FD70.002D ret wc
Finally got all the opcodes entered although some still need some rules specified. But what I got out of this is that even though this assembler has not been optimized in a whole lot of ways it doesn't take up much code space, in fact the figures are:
CODE: 3519 bytes
NAME: 2159 bytes
There is no need for me to optimize anything at present but if I did want to squeeze it up I could probably cut that code in half.
Since I want to check out assembly code and how some of the opcodes work I will concentrate more on that aspect now and leave the preprocessor until a little later.
I keep getting sidetracked with this assembler but have made some improvements which now allow me to use labels as well. So I can create a CODE definition which makes a new word in the dictionary that is pure assembly code and it can use backward references which are easy enough but also forward references with a little trick since it's only single pass when the source is pasted in. There are still a few things I need to do with processing an opcode properly (spot the bugs) but here is some mashed code that I ran through the assembler as part of the test.
Preprocessor is still to come but essentially it will be inserting whitespaces in all the right places before letting the standard Forth parser grab what basically looks like the right column of this listing. This is the raw source at present of that test code.
CODE (SDRD)
jmp # l3
mov x , 2nd
mov r2 , # 256
shl r2 , # 1
label l1
mov r1 , # 8
label l2
andn outa , sck
test miso , ina wc
rcl r0 , # 1
or outa , sck
djnz r1 , # l2
andn outa , sck
wrbyte r0 , x
and r0 , # $FF
cmp r0 , tos wz
if_z add acc , # 1
if_z cmp acc , # 1 wz
if_z mov 2nd , x
add x , # 1
djnz r2 , # l1
label l3
ret
END
Help me with context:
This inline assembler is written in TF and runs on the P2?
One purpose of its creation is to test P2 instructions?
Do you have plans for it after that?
Seems like it would be a great tool even for those just interested in assembly coding in a self-hosting environment.
All pure P2 Tachyon Forth stuff here, and loving it.
The original purpose was so I could write assembly code definitions mixed in with the Forth code. Small assembly modules are required for the fastest speed such as accessing SD memory where typically most of the code is in high level Forth and I can test out the low-level access in Forth initially after which when the function is proven those couple of low-level words can be rewritten in assembly.
But the real impetus for this was when Seairth started his opcode testing and I knew I could probably make that testing come alive interactively but I needed the assembler working.
So assembler programmers will probably love using the TF2 assembler as you get to see the code it produces and you can test the sub-routines interactively since TF2 uses sub-routine threading anyway. You can call by address or by name and maybe a simple undo will allow the previous line(s) to be interactively edited again without reloading. A simple RET will bring you back to the console and I will include routines for displaying status bits etc although it is very easy to do this yourself.
When I fire up the SD card and filesystem utilities soon I may just include a screen editor for ANSI terminals which means we can edit code and compile straight from the command line rather than copy/paste from the PC. It will be fast for sure and also means that you can use your tablet for a terminal over serial or Bluetooth. I know my Xperia handles FTDI serial directly although I mostly use Bluetooth serial.
Then there are the debug interrupts that we can start playing with too, but later
So assembler programmers will probably love using the TF2 assembler as you get to see the code it produces and you can test the sub-routines interactively since TF2 uses sub-routine threading anyway.
For serious Assembler work, you would need Symbols, Assembler Expression evaluation, some directives, and then macros.... stuff probably best done PS-Side.
- but I can see the appeal of a paste&try vanilla Assembler.
( One of my favorite calculators uses an editor pane and does paste&try.)
An approach I have thought about is a PC-side assembler that exports an ASM version of the LST file.
- ie post expression evaluation, conditionals, includes, macros etc, as that is 'portable assembler' and could also come from a HLL.
There is appeal to sending simplest ASM info, over using more cryptic HEX-blobs.
To support that simplest-assembler, I think you just need Symbols added ?
The beauty of Forth is what Peter has got done is enough to write as much of a better assembler as one would want.
Nice work man!
I wish I got along with Forth better. This is where it really shines. Bootstrapping onto a new CPU. Doesn't take too much, and one can throw a whole dictionary at it, and be up and running lots of stuff.
I'll definitely have a play when Peter lets it go.
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.
My rudimentary system at present uses predefined constants l0 l1 l2 l3 l4 etc which can be set to the current PC using "label l2" for instance. Forward references just save the save current PC so that when label is executed later it will link back to that instruction.
Once I have editing using the SD filesystem and ANSI terminals I can include symbols to my hearts content as it is easy to perform multiple passes as necessary. Remember that this is a macro-assembler in that we can create Forth definitions that can perform all kinds of fancy stuff.
btw, there is a link to the dropbox files but you will have to hunt for it. Consider it part of the fun. No effort, no joy, no fun.
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.
Comments
SETQ longcount
WRLONG #0,startaddress
BTW, thanks for the tip too.
I imagine you mean ALTDS, not SETQ here.
ALTDS could be used to set an immediate D. It just substitutes the D field bits.
This is small enough, you may be able to just have versions for Byte/Word/Long and if users want speed, they choose 32b aligned data ?
Most would understand that.
That may not be larger than the housekeeping needed for a long/byte split speed up.
I noticed that there is a Winbond 25Q80 on the DE2-115 add-on board which I guess is used for P2 boot when it's available. In the meantime I'm looking at using this for some temporary backup to hold source code files and binary images.
Are these the right pins for the chip? In the meantime I will start writing some code to access the chip after which I may bundle it in the PNut compiled kernel itself so that it is ready to load from there. I see that there is an SD card socket on the DE2, is that accessible from the P2? I could probably get the SD card up and running faster than the serial Flash and it's more useful. If it's not accessible I may just add one.
rev tos1,tos
where tos1 was the value that had to be reversed by tos bits but in the P2 this doesn't work where I want to:
in the P1 with the exact same code I get: and
Checking the P2 code: So S and D are correct except for the I field which according to the instructions is %100110001 so it looks like an assembler bug.
Nope, that must have been a typo on my part, I've checked and it is %100110010 (ICZ) so that's correct. But REV is not working as it should.
BTW, I found a bug with SUBX too, is there one place where we can report these bugs or observations.
Chip sees 'em, be it bug or request. Others also understand that they too should go and test 'em.
Just start a new thread on the topic. That way, we all see it, can help verify/troubleshoot, and make sure that follow-up comments don't get buried in another thread (like this one).
Now on to the next step of interfacing to the SD card which I will have to hook-up probably to the same pins as the serial Flash except I will give the SD card its chip select on P57.
Now if that all works then the next step is the W5500 module for some P2 networking!
Here I erase a 64k chunk at address 0 for the test, dump it using SF to modify DUMPs behaviour, check RAM at the same address, backup and check and also check 256k boundary in serial Flash.
Is that in QuadSPI mode, or the slower 1b SPI ?
I can't wait until we can all play Tachyon2
Oh, I haven't bothered releasing it because I didn't think anybody could be bothered! ( what with all the debates which are far more "interesting")
But I will add a couple of extras now before I put it out there, that is, if anybody wants to play.
I have a simple infix mode so that I can enter the assembly code in the same fashion as we would for PNut but it also generates a listing, both as hex and also as bit fields. So this might take me a day or two to get all the opcodes entered and addressing modes sorted out but the other benefit of this is that I can then start writing assembly language drivers for Tachyon in Tachyon itself.
Here's the skeleton of my assembler in just a few lines:
{ TF2 P2 ASSEMBLER TF2 ASM format is the same as PASM if_z ROR tos1,tos wc,wz } long opcocde pub EFF! MASK opcode SET ; pub wc #20 EFF! ; pub wz #19 EFF! ; pub # #18 EFF! ; pub CC! #28 SHL opcode @ $0FFF.FFFFF AND OR opcode ! ; pub if_c %1100 CC! ; pub if_z %1010 CC! ; pub always %1111 CC! ; \ Write opcode 7+3-bit opcode field and set default conditions etc pub OPC! #18 SHL opcode ! always ; pub ROR %0000000.000 OPC! ; pub ROL %0000001.000 OPC! ; pub SHR %0000010.000 OPC! ;I will likely give this a play when it's ready Peter. A quick 'n easy, type it in and go scenario is appealing.
The infix mode simply defers some actions until the end of the line while allowing commas and other lack of whitespace, So there is no special syntax unless I really enforce it so all kinds of "macros" are possible too.
In here I compare the result with what should be the equivalent in the Tachyon kernel. Then I decide I'd like a "macro", so I make one to help with that too.
Well I'm still entering the opcodes and along the way I am testing what I have and what I need to do which may include some extra class information with the opcodes too. The preprocessor will come last but in the meantime it's quite interesting how you can mix your directives and operands around like this:
I don't expect this to be bug free at present as the -4 in the djnz corrupted the opcode etc. But I do like the fact that the conditional execution directives such as if_c can be placed at the end of the line.
Just seen Seairth's post about these instructions, so I will have to play with that too.
CODE: 3519 bytes
NAME: 2159 bytes
There is no need for me to optimize anything at present but if I did want to squeeze it up I could probably cut that code in half.
Since I want to check out assembly code and how some of the opcodes work I will concentrate more on that aspect now and leave the preprocessor until a little later.
TF2# WORDS 3481 EXEC 3477 END 3461 ASM 3419 AEVAL 33FD APROMPT 33F1 augd 33E5 augs 33D9 loc 33CD calld 33C1 callb 33B5 calla 33A9 call 339D jmp 338B retb 3379 reta 3367 ret 3355 pop 3343 push 3331 callb 331F calla 330D call 32FB waitx 32E9 jmprel 32D1 stalli 32B9 allowi 32A7 setint3 3295 setint2 3283 setint1 326B waitfbw 3253 waitxro 323B waitwrl 3223 waitrdl 320B waitedg 31F3 waitpat 31DB waitcnt 31C3 waitint 31AB pollfbw 3193 pollxro 317B pollwrl 3163 pollrdl 314B polledg 3133 pollpat 311B pollcnt 3103 pollint 30F1 setwrl 30DF setrdl 30CD setedg 30BB getxsin 30A9 getxcos 3097 setxfrq 3085 setxdac 3073 getrnd 3061 getcnt 304F getqy 303D getqx 302B setq2 3019 setq 3007 qexp 2FF5 qlog 2FE3 lockset 2FD1 lockclr 2FBF lockret 2FAD locknew 2F9B cogstop 2F89 cogid 2F77 clkset 2F6B wrlut 2F5F msgout 2F53 jnp 2F47 jp 2F3B setpbn 2F2F setpbe 2F23 setpan 2F17 setpae 2F0B rdlut 2EFF msgin 2EF3 calld 2EE7 addcnt 2EDB tjns 2ECF tjs 2EC3 tjnz 2EB7 tjz 2EAB rolword 2E9F getword 2E93 setword 2E87 rolbyte 2E7B getbyte 2E6F setbyte 2E55 nn 2E49 rolnib 2E3D getnib 2E31 setnib 2E25 qvector 2E19 qrotate 2E0D qsqrt 2E01 qfrac 2DF5 qdiv 2DE9 qmul 2DDD coginit 2DD1 rep 2DC5 xcont 2DB9 xzero 2DAD xinit 2DA1 fblock 2D95 wdfast 2D89 rdfast 2D77 wflong 2D65 wfword 2D53 wfbyte 2D41 rflong 2D2F rfword 2D1D rfbyte 2D0B setbrk 2CF9 setcz 2CED wrlong 2CE1 wrword 2CD5 wrbyte 2CC9 rdlong 2CBD rdword 2CB1 rdbyte 2CA5 gets 2C99 sets 2C8D getd 2C81 setd 2C75 seti 2C69 rev 2C5D seussr 2C51 seussf 2C45 mergew 2C39 splitw 2C2D mergeb 2C21 splitb 2C15 movbyts 2C09 setbyts 2BFD testb 2BF1 anyb 2BE5 test 2BD9 testn 2BCD djns 2BC1 djs 2BB5 djnz 2BA9 djz 2B9D muls 2B91 mul 2B85 decmod 2B79 incmod 2B6D botone 2B61 topone 2B55 decod 2B49 altds 2B3D negnz 2B31 negz 2B25 negnc 2B19 negc 2B0D neg 2B01 abs 2AF5 not 2AE9 mov 2ADD muxnz 2AD1 muxz 2AC5 muxnc 2AB9 muxc 2AAD xor 2AA1 or 2A95 and 2A89 andn 2A7D setbnz 2A71 setbz 2A65 setbnc 2A59 setbc 2A4D setb 2A41 clrb 2A35 notb 2A29 isob 2A1D sumnz 2A11 sumz 2A05 sumnc 29F9 sumc 29ED maxs 29E1 mins 29D5 max 29C9 min 29BD cmpsub 29B1 subr 29A5 cmpm 2999 cmpr 298D cmpsx 2981 cmps 2975 cmpx 2969 cmp 295D subsx 2951 subs 2945 subx 2939 sub 292D addzx 2921 adds 2915 addx 2909 add 28FD sal 28F1 sar 28E5 rcl 28D9 rcr 28CD shl 28C1 shr 28B5 rol 28A9 ror 2893 OPC! 2887 never 287B always 286F if_c<>z 2863 if_c=z 2857 if_nc_or_nz 284B if_nc_or_z 283F if_c_or_nz 2833 if_c_or_z 2827 if_c_and_nz 281B if_c_and_z 280F if_nz 2803 if_nc 27F7 if_z 27EB if_c 27CD CC! 27B7 # 27AB wz 279F wc 2793 EFF! 2789 orgh 277F org 2771 , 2771 d 2761 s 2759 pushx 2751 drop 2749 4th 2741 3rd 2739 2nd 2731 1st 2729 tos 2721 aflags 2719 pc 2711 opcode 26D2 P2ASM.fth 26C6 BOLD 26BA REVERSE 26AE PLAIN 26A0 ATR 267D CURSOR 266B ERLINE 265B CLS 2649 ERSCN 263D HOME 2629 XY 2619 CUR 260B .PAR 25FF PEN 25F3 PAPER 25DD COL 25CF ESCB 25C1 ESC 25B9 white 25B1 cyan 25A9 magenta 25A1 blue 2599 yellow 2591 green 2589 red 2581 black 1008 LONG 256B ALIAS 255D UNSMUDGE 2551 IMMEDIATE 2545 @HATR 253B @NAMES 2517 SF 24F9 SF@ 24E1 SFW@ 24D1 SFC@ 24C5 RAM 24A9 BACKUP 2485 SFWRBLK 2465 SFWRPAGE 2455 SFERCHIP 2443 SFER64K 2431 SFER32K 241F SFERSEC 2405 SFRDBLK 23ED SFADR 23DD SFJID 23C7 SFSID 23B1 SFRDS 23A7 SFWD 239D SFWE 2393 SFINS 2389 SFCS 2381 sfdo 2379 sfdi 2371 sfck 2369 sfcs 234E COGLIST 22EC .INS 22CC .P 22C0 SPACES 22AA EMITS 2246 BMAP 222E .ADDR 2224 COGREG! 221A COGREG@ 21CA WORDS 21A6 WTAB 218C CTYPE 214B FIBOS 2135 fibo 20EE .LAP 20E4 /LAP 20CA LAP 20C2 K1 20BA L3 20B2 L2 20AA L1 20A0 ALLOC 2094 W~ 2088 C~ 207C ~ 2048 LEDTASK 2040 DLY 0020 DUP 0023 OVER 001A DROP 0019 2DROP 002C SWAP 0030 ROT 001D NIP 0029 BOUNDS 000C STREND 14BF STRLEN 0181 0 0180 1 017F 2 017E 3 017D 4 017B 5 017A 6 0179 7 0178 8 0177 9 0175 0D 0182 ON 0182 TRUE 0182 -1 0173 BL 0174 16 0181 FALSE 0181 OFF 003A 1+ 0037 1- 0039 2+ 0036 2- 0034 + 0033 - 00D7 ADO 00D8 DO 00E2 LOOP 00DF +LOOP 00D9 FOR 00EA NEXT 0089 I 008B J 0087 IX 0041 INVERT 0043 AND 0045 ANDN 0047 OR 0049 XOR 004F ROL 0051 ROR 004B SHR 004D SHL 0053 2/ 0055 2* 0057 REV 0059 MASK 005D >N 005E >B 005F 9BITS 0063 0= 0063 NOT 0061 = 0067 <> 006B > 0071 C@ 0073 W@ 0075 @ 0077 C+! 0079 C! 006E C@++ 007B W+! 007D W! 007F +! 0081 ! 13C1 SET 13D1 CLR 1126 SET? 00FE UM* 00FA * 00F8 ABS 003C -NEGATE 003D ?NEGATE 003F NEGATE 00AE HIGH 00B4 LOW 00BA FLOAT 00C5 SHROUT 00C2 SHRINP 1F52 DIRX 1F5E OUTX 1F6A INX 0098 PA@ 009A PB@ 009C PA! 009E PB! 00A0 DACLR 00A2 DBCLR 00A4 PASET 00A5 DASET 00A7 PBSET 00A8 DBSET 00AA PACLR 00AC PBCLR 00BC PIN@ 0000 RESET 0013 0EXIT 0015 EXIT 0017 NOP 0018 3DROP 001F ?DUP 0025 3RD 0027 4TH 00C8 CALL 00CC JUMP 00E7 BRANCH> 00EE >R 00F1 R> 015A >L 00DD L> 0169 !SP 0171 !RP 016F !LP 016D !BP 1BC5 DEPTH 013A COG@ 013F COGREG 0141 COG! 0146 COGID 00F6 @REG 1C85 KEY 1C81 KEY! 1C85 KEYB 1BFB READBUF 18B0 DISCARD 011B EMIT 09F8 CR 01AC SPACE 011E CNT@ 1BA1 ERROR 1228 QD 1230 DUMP 1254 DUMPW 127A DUMPL 12A0 DUMPA 1318 COGDUMP 11A0 .BYTE 11B0 .WORD 11C0 .LONG 14E3 . 14E3 PRINT 13E1 @PAD 13F3 HOLD 1405 >CHAR 1497 #> 1433 <# 1447 # 1487 #S 14B3 <D> 1521 PRINT$ 14BF LEN$ 14F9 U. 1535 .DEC 0998 U/ 0988 U/MOD 09A2 */ 0069 0< 006A < 0A06 U< 110E WITHIN 1134 ?EXIT 014E ERASE 014F FILL 0125 CMOVE 1144 <CMOVE 115E ms 09D0 HEX 09C4 DECIMAL 09B6 BINARY 1733 GETWORD 174F SEARCH 0C7C NUMBER 1BCD .S 13B5 HERE 0F2E @HERE 1E05 CLS 1D9D HOME 1DB7 PEN 1DB3 PAPER 1DF1 XY 1E77 BOLD 1E59 PLAIN 1E6F REVERSE 1F43 dmpvec 1F3E flags 1F2A base 1F39 temp 1F2F prompt 1F34 accept 1F48 names 18CC TASK 1F4D rxptr 1F76 GETRND 1080 ||| 0F54 CREATEWORD 0FF4 CREATE 1008 VARIABLE 1014 CONSTANT 1014 == 102C ALLOT 10E2 [COMPILE] 10E2 [C] 0F08 GRAB 10AA pub 0F46 pri 108C : 10BA ; 0ED8 NFA' 0EF2 ' 0DAC IF 0DC8 ELSE 0DFA THEN 0DFA ENDIF 0D3E BEGIN 0D50 UNTIL 0D92 AGAIN 0DAC WHILE 0D6A REPEAT 1D0B \ 1D0B '' 1D0B --- 1D2F ( 1D5F { 0017 } 1D53 IFNDEF 1D45 IFDEF 0E34 " 0E44 ." 1174 (.") 1FBA SFRD 1F96 SFWR 002B +FIB 1B06 UNKNOWN 1B44 NOTFOUND ok TF2#Preprocessor is still to come but essentially it will be inserting whitespaces in all the right places before letting the standard Forth parser grab what basically looks like the right column of this listing. This is the raw source at present of that test code.
CODE (SDRD) jmp # l3 mov x , 2nd mov r2 , # 256 shl r2 , # 1 label l1 mov r1 , # 8 label l2 andn outa , sck test miso , ina wc rcl r0 , # 1 or outa , sck djnz r1 , # l2 andn outa , sck wrbyte r0 , x and r0 , # $FF cmp r0 , tos wz if_z add acc , # 1 if_z cmp acc , # 1 wz if_z mov 2nd , x add x , # 1 djnz r2 , # l1 label l3 ret ENDThis inline assembler is written in TF and runs on the P2?
One purpose of its creation is to test P2 instructions?
Do you have plans for it after that?
Seems like it would be a great tool even for those just interested in assembly coding in a self-hosting environment.
The original purpose was so I could write assembly code definitions mixed in with the Forth code. Small assembly modules are required for the fastest speed such as accessing SD memory where typically most of the code is in high level Forth and I can test out the low-level access in Forth initially after which when the function is proven those couple of low-level words can be rewritten in assembly.
But the real impetus for this was when Seairth started his opcode testing and I knew I could probably make that testing come alive interactively but I needed the assembler working.
So assembler programmers will probably love using the TF2 assembler as you get to see the code it produces and you can test the sub-routines interactively since TF2 uses sub-routine threading anyway. You can call by address or by name and maybe a simple undo will allow the previous line(s) to be interactively edited again without reloading. A simple RET will bring you back to the console and I will include routines for displaying status bits etc although it is very easy to do this yourself.
When I fire up the SD card and filesystem utilities soon I may just include a screen editor for ANSI terminals which means we can edit code and compile straight from the command line rather than copy/paste from the PC. It will be fast for sure and also means that you can use your tablet for a terminal over serial or Bluetooth. I know my Xperia handles FTDI serial directly although I mostly use Bluetooth serial.
Then there are the debug interrupts that we can start playing with too, but later
For serious Assembler work, you would need Symbols, Assembler Expression evaluation, some directives, and then macros.... stuff probably best done PS-Side.
- but I can see the appeal of a paste&try vanilla Assembler.
( One of my favorite calculators uses an editor pane and does paste&try.)
An approach I have thought about is a PC-side assembler that exports an ASM version of the LST file.
- ie post expression evaluation, conditionals, includes, macros etc, as that is 'portable assembler' and could also come from a HLL.
There is appeal to sending simplest ASM info, over using more cryptic HEX-blobs.
To support that simplest-assembler, I think you just need Symbols added ?
Nice work man!
I wish I got along with Forth better. This is where it really shines. Bootstrapping onto a new CPU. Doesn't take too much, and one can throw a whole dictionary at it, and be up and running lots of stuff.
I'll definitely have a play when Peter lets it go.
My rudimentary system at present uses predefined constants l0 l1 l2 l3 l4 etc which can be set to the current PC using "label l2" for instance. Forward references just save the save current PC so that when label is executed later it will link back to that instruction.
Once I have editing using the SD filesystem and ANSI terminals I can include symbols to my hearts content as it is easy to perform multiple passes as necessary. Remember that this is a macro-assembler in that we can create Forth definitions that can perform all kinds of fancy stuff.
btw, there is a link to the dropbox files but you will have to hunt for it. Consider it part of the fun. No effort, no joy, no fun.
It was not clear how far those reached, or if they were to a 'paste-able' level.