Jump to content

TheBF

+AtariAge Subscriber
  • Content Count

    2,874
  • Joined

  • Last visited

Everything posted by TheBF

  1. Your are such an expert on this system. Thanks for all the insights! Forth does almost nothing without explicit code so no, there are not breaks in the loops. :-) But it can be done by re-defining the loop words like this: \ example to add BREAK to Forth BEGIN/UNTIL loops : ?BREAK ( -- ) KEY? ABORT" HALTED BY USER" ; : UNTIL ( ? --) POSTPONE ?BREAK POSTPONE UNTIL ; IMMEDIATE That's something that is difficult in conventional languages. :-) However to your point this would slow the loops down to 1000 loops per second because of the infernal KSCAN. So maybe this is why Pascal is operating slowly. Maybe you should compare a different benchmark that unrolls a loop into many lines of sequential code and see if things speed up. ?
  2. From the benchmark result Apersson850 posted, there is room for improvement. Since the Pascal compiler is written in Pascal, the slowdown seems to be in the p-code interpreter implementation. If the Pascal compiler emitted Forth that was r"linked" by Turbo Forth and then run, I have a strong feeling it would be much faster than it is currently. Of course if the Pascal compiler emitted native TMS9900 code it would be comparable in speed to C that we see from GCC and potentially the compiler would run even faster on the TI-99. The caveat is that the compiler program might be larger as native code, but with appropriate compiler optimizations it could be made to be comparable size. Pascal normally compiles much much faster than C, comparable to Forth compilation speeds, because of C's more complicated grammar so I go back to the p-code interpreter as the most probable bottle-neck.
  3. Wow. That is very peculiar to me. If you replaced the P-code system, a stack VM with a Forth stack base VM I am certain that Pascal code compiled to Forth would still run much faster than your results even with the run-time tests that Pascal incorporates. Does this indicate that there is a significant amount of GPL in the P-code interpreter?
  4. Not sure if this gives you a little help, but it's an illustration in a manual I am working on. The Forth Programming Pyramid You program in Forth by adding functionality to the Forth system itself. Your WORDs are added to the system word by word and you can test each word as you go. This makes your pyramid of code very solid and reliable. · Assembler CODE words are the foundation of the language that control the computer hardware · The Forth language is normally written using a mix of those Assembler words and Forth · Your program’s words are just more words added to the system. No different than the Language itself. · All of this culminates in creating the final word that starts the entire program running which you can call anything you like. RUN is as good as any other. ​The word "RUN" in the pyramid could be anything, but it shows the last word (sub-routine) you create kicks off your entire program.
  5. Another way to go is to create a set of words that emulate the functionality of TI-BASIC to give you some higher level building blocks. Turbo Forth already has many of them already. For example: \ CALL clear in CAMEL99 Forth (Consult Turbo Forth docs for equivalent words) DECIMAL : CLEAR ( -- ) PAGE 0 23 AT-XY ; ( just because you love it ) \ make an input buffer CREATE BUF$ 80 ALLOT : INPUT$ ( -- BUF$) PAD DUP 80 ACCEPT BUF$ PLACE ; : INPUT# ( -- number) INPUT$ BUF$ ?NUMBER 0= ABORT" not a number" ; Warning CAMEL99 Forth "tries" to keep to Forth 94 standard. TF is Forth 83 Standard so there are some differences, but Willsy can give us the translations. ​
  6. Try writing an outline for the game like you would for an essay. The titles of the outline are the word names for the big blocks of the game. The names in the bullet points become the internal routine names. In other words design top down ... Then figure out how to build it Bottom up, testing your words as you build. Try the outline and post it here and we can give you support.
  7. That's a fun project. I am a musician and producer myself but have been programming for almost as long. Another exercise for you could be to open a file and have your note frequency calculator program print the values out to a file as BASIC DATA statements. Sort of like below. BUT please read the manual on the OPEN statement, I have not used TI BASIC for many years so my memory is faulty. 5 OPEN #1:"FILENAME" BLAH BLAH (check your manual) 10 LET F=110 20 FOR I=1 TO 91 30 PRINT #1: I * 100;" DATA "; F 40 LET F=F*92^(1/12)) 50 NEXT I 60 END But if you make the text file you could use it like a prefab building block for future music programs. Just an idea.
  8. Lol. It sounds Friday evening has started in Uk.😄
  9. This book has been the defacto text for many years and is a good adjunct to Willsys pages https://www.forth.com/starting-forth/0-starting-forth/
  10. I like the idea Mark. I am moving house but once we get settled I could help with editing and audio. I have a home studio. Well I did ... and will make a new one. Send me an email if you want to collaborate
  11. FYI by "easier to use" I mean it is interactive in a way that is hard to imagine for Assembly language programmers. You can write a simple code routine at the console like in BASIC and test it immediately. Do this a few times and join them all together as a high level Forth routine and test that interactively. It's pretty fun. B
  12. Well... Turbo Forth has its own Assembler. Which is easier to use than the TI assembler. So real Forth programmers write in Forth then optimize the right loops with Forth Asm routines. If you check the Tursi benchmarks postings you will see that I got the benchmark down to 6.5 seconds in Forth versus 5 seconds in the optimized Assembler version. And if I needed 5 seconds I would just write the outer loop in Forth Assembler too. Remember when Tursi re-wrote the code using BLWP system calls the way you would start a project it took 17 seconds versus 48 seconds in in-optimized turbo Forth. That is less than a 3 times difference in an apples to apples type comparison. There are industrial examples at Forth Inc where they rewrote customers products that were in Assembler or C where the final Forth version was faster because they could test algorithms interactively and find better methods to solve the problem. Algorithms normally beat language. BF
  13. I was just reading a paper on porting systems and it included these two quotes by famous computer scientists. Thought I would share here. I love the 1st one! And I have some experience to prove he's correct. "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." (Brian Kernighan) "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague." (Edsger Dijkstra)
  14. How much faster is this than putting the one byte write line in a loop. Have you Measured it?
  15. Where do the robust libraries come from for your business? In house?
  16. Cool! Ya it's not too tricky to get started. The gotchas come on things like DEFER and TO where you have to remember to skip past the code fragment at the front of the word to get to the parameters. And if you plug in the addresses of code words anywhere you need remember to NOT skip over anything because there is nothing to skip. And it does make things a little bigger. On my system it added 220 or so bytes... not good news for a packed cartridge.
  17. Yes very different. A good cooperative tasker sounds like it would not be reliable but with fine grained control in the Forth environment you can tune the tasks very precisely. And when external inputs must be dealt with you only need to put the data acquisition routine(s) on an interrupt and queue the data somewhere. And problems with locks and semaphores disappear because you design routines to run to completion or exit at convenient places. There are some pretty big projects running this way on Forth systems. So here is a demo video that runs this code that just flails away at the screen with '-' and '.' while the console is still running. There is a bar graph task, showing the CPU loading, installed but I didn't run it in the video. 2taskdemo.mov
  18. Very sound advice for a preemptive task switcher. The Classic Forth task switcher is cooperative relying on much faster context switch times than is normal and switch only after I/O routines run to completion. All I/O routines are keep fast as well to allow smooth operation. Remarkably simple but also efficient. Forth Inc's Polyforth system could hang 150 dumb terminals on a i386 machine and users didn't complain. I know that sounds ridiculous, but they did it. So I will create a demo for you, but I know that there will not be an issue , because there are no surprises with these systems. They switch when you say and only when you say with a function called PAUSE but at very atomic intervals compared to what you are used to with other cooperative tasking systems. But to your point in your example, referencing via a register (R13) will not be a problem. But dead reckoning of an address in the code as a literal is.
  19. But SWPB+MOVB R0, <symbolic> is the same size as MOVB <symbolic>,<symbolic> and only uses 2 more cycles. Or am I missing something else?
  20. Actually the code I provided was Assembler, just a reverse Polish notation assembler. :-) <oldmanlecture> A very cool concept in Forth is the concept of compiling being nothing more than putting numbers into memory. (hopefully the correct numbers) There is an operator called "comma" and it looks like this , It is a number "compiler" in Forth. It takes a number from the stack and puts in in the next available memory location and incs the memory pointer by 2 bytes (for 16 bit machines) Typical usage would be just like a data statement HEX CREATE MYDATA DEAD , BEEF , ADDA , FFFF , MYDATA is equivalent to a label. Notice how you need to last comma to "compile" the last number into memory. With that little comma and some logic you can make an assembler in an afternoon. The weird thing is it's not a progam! Each mnemonic is it's own little assembler for 1 instruction. It's a totally different way to think about translating text to machine code. But since arguments go on the stack the registers come first then the instruction. </oldmanlecture> We now return to our regularly scheduled program.
  21. Ahh.... but you must pay for your sins for using register sorcery! I just realized that by referencing Registers as memory it makes all my code routines break as soon as I jump to a new task which has a new work space. Now I could use a slower muli-tasker that stays in 1 workspace, but how cool is it to have 20uS task switch on a TI-99?
  22. Yes that was what you had the benchmark do. These are clever tricks. I always knew it could be done, but thought it would be slower than using the instructions as designed. Wow. What a sad story for the 9900 designer. :-) So if I read the 9900 manual correctly: Using SWPB followed by MOVB R0,@>xxxx is 10+14+8 = 32 cycles, 6 bytes but using MOVB @>XXXX,@>yyyy adds is 14+8+8= 30 cycles, 6 bytes Correct?
×
×
  • Create New...