yock1960 wrote: ↑Wed Jan 17, 2024 11:02 pm ... Additionally, I added being able to perform bitwise 'and' using the & symbol. I think that Turbo Pascal used 'and' for both boolean and bitwise operations, but this was the easiest path for me. ...
Under more modern Pascal's, there are some Boolean types which are 0 or 1, and there are Boolean types which have any non-zero value being True, but all bits are set when the value is set to True. But I don't think a pcode Pascal for the X16 needs to worry about the full range of some 9 different boolean types.
I know that for the m-code Pascal, "true" was 1, so while boolean AND would be allowed to set the return value zero and then increment if the and of the two low bytes is non-zero, bitwise AND of $0001 & $0001 is $0001, and either or both $0000 gives $0000. OR would also work both bitwise and boolean. I think XOR also works ... $0000 XOR $0001 (or the reverse) = $0001, $0001 XOR $0001 = $0000, $0000 XOR $0000 = $0000. So the core function that needs different bitwise and boolean is the NOT, where a Boolean NOT needs to filter the high bits to 0 to keep boolean functions clean for more complex operations, and a bitwise NOT shouldn't filter the high bits.
yock1960 wrote: ↑Wed Jan 17, 2024 11:02 pm ... Additionally, I added being able to perform bitwise 'and' using the & symbol. I think that Turbo Pascal used 'and' for both boolean and bitwise operations, but this was the easiest path for me. ...
Under more modern Pascal's, there are some Boolean types which are 0 or 1, and there are Boolean types which have any non-zero value being True, but all bits are set when the value is set to True. But I don't think a pcode Pascal for the X16 needs to worry about the full range of some 9 different boolean types.
I know that for the m-code Pascal, "true" was 1, so while boolean AND would be allowed to set the return value zero and then increment if the and of the two low bytes is non-zero, bitwise AND of $0001 & $0001 is $0001, and either or both $0000 gives $0000. OR would also work both bitwise and boolean. I think XOR also works ... $0000 XOR $0001 (or the reverse) = $0001, $0001 XOR $0001 = $0000, $0000 XOR $0000 = $0000. So the core function that needs different bitwise and boolean is the NOT, where a Boolean NOT needs to filter the high bits to 0 to keep boolean functions clean for more complex operations, and a bitwise NOT shouldn't filter the high bits.
All moot at this point, since while '&' works, it appears to cause other problems and I haven't been able to figure out why. No other bitwise operators will be added until I do and it's probably best to avoid using '&'.
Unfortunately, while adding bitand (&) gives a correct value, it causes some undesired behaviour in certain situations, which...yet again, I do not understand why! If I had a nickel for every time I have said this to myself during the adaptation of Pascal-S to Prog8, while I wouldn't be rich, I would have filled my pockets to overflowing, of nickels! I haven't removed it from the compiler and interpreter yet, but be warned. It took way longer to work out a workaround, but in the end, I figured out a way. Here is a complete rendition of the program, published in the May 1988 issue of Transactor Magazine. Cellular automata are quite interesting and can generate some fascinating visual images, especially if you're fond of triangles!
This 350 or so line program got extremely close to the 2000 p-code limit while I was developing it, so I have increased the p-code/address/data space to take up the whole of a bank of hiram. So now the limit is 2730. Probably no one will need that much, but you never know.
The latest versions of the compiler, interpreter and the automata app have been uploaded and are available in the zip file attachment at the 1st post in this thread.
Through various improvements to all 3, the draw time for the automata display is reduced from 153 seconds to 115 seconds. This breaks down to 4 seconds to pascal code optimization, 4 seconds to compiler improvements and the rest to optimization in the interpreter. The compiler improvements also cuts down code/data usage when using 'call' (kernal calls), 9 bytes per each previously, now only 3. So, for the cellular automata app, that's a nearly 33% improvement in execution speed!
These improvements also show a 29% speed improvement for the sieve.pas program.
I've made some progress on the issue with records, but there are still problems. Hoping to have them working in a week or so.
Other changes, I have eliminated the echoing of the pascal file to screen. I got tired of watching it scroll by, which takes some time. I also have changed the list code display, to show hex values for hardware addresses, keeping decimal values for character values and also for 'virtual machine' addresses. If I can figure out a way that's not too difficult, I would also like to have the list code display the subroutine and variable names, next to the values. As a 'sop' I may allow writing the 'code display' to be written to a text file. Additionally, the interpreter no longer asks for a key press, but will pause 2 seconds, before interpreting the code.
I have it in mind to allow writing the p-code and data to files and having a 'loader', that will load the p-code files and interpreter (runtime) and start execution.
New changes! I have increased the identifier maximum from 100 to 128, after exceeding this limit when making changes to the automata app. Why 128? Prog8 limits arrays to 256 bytes, the data structure for identifiers contains words, as well as bytes. It does allow up to 512 byte arrays if you use a special modifier (@split) when declaring the array, but I've never used this and there are potential issues, so for now...128 is the maximum. I have also fixed the check for violating this limit, which wasn't working, so now instead of crashing, you will recieve an error message. Execution speed is also a few percent faster, after what is probably the last of the 'low hanging fruit' optimizations. New versions of automata and sieve programs also, which gets rid of the 'seconds' only time result, which made the resolution a bit coarse.
Starting with this version, I have made a 1st attempt at more informative error messages. Often, you will just get 'syntax error', for things like a missing semicolon, which will probably be on the line previous to the one displayed. I have tested a few simple cases, but if you find an error message that doesn't make sense to you...please drop a note here! I have also eliminated one case where an error trap wasn't working correctly and caused a hung program. Now generates an error message.
I did a thing! Hence, not only a new version, but a new name. From here on out, until such time that I am able to make my version more conformant to 'standards', this will be known as Pascal-ish, since there are differences. So, what did I do? While working on my little automata app, I lamented the lack of a way to set the arrays that I use to hold the 'code', other than one cell at a time. BASIC has READ/DATA, where you can setup a loop to fill an array. Pascal-S...nothing like...until Pascal-ish came to be! I have expanded the READ command to be able to fill arrays like so:
READ(code[0],'1231231230'); for integer arrays
or
READ(strarray[0],'this is a string'); for char arrays
this is still a work in progress. For example, currently the integer array functionality is only useful for cases where each cell is a value from 0-9, single character values in other words. At this time, only literal (no variables) can be used as the array subscript in the 'declaration'. I'll work on this, also I will work on expanding to allow comma seperated values for integers and I guess also for char, to allow the full 'ascii/petscii' character sets to be used. For 'strings' or char arrays, the 1st byte of the array is used to hold the length of the string. I'm still thinking about this....so stay tuned. Also, see the source files included in the new .zip in post #1 (arrayt5.pas & automataq.pas) for current usage. As an additional benefit, this useage saves a bit of p-code per each array element filled. Minus overhead for multiple 'reads', for the automata app, it reduced the p-code size by about 200.
Note! While developing the example program for string usage and the string functions, several times the compiler generated errors for reasons that eluded me. After some head scratching and muttering under my breath, I remembered that the compiler and parser sometimes have issues with whitespace (typically tabs) at the end of lines or on an empty line. I use Notepad+ to write my Pascal-iSh code, a very old version (I'll update it one of these days) and it has a setting to show all characters, including whitespace. Perhaps, for reasons that I don't understand, this is an issue specific to Notepad+ (the errors relating to extraneous whitespace), I don't know, but if you have perplexing errors, get rid of extra tabs or spaces at the end of lines or on empty lines and see if that helps. It's annoying, but it's also low on my priority to fix, especially since the parser 'eats' all whitespace to begin with, so, it's somehow related to how Prog8 determines the end of a line and is beyond my control, short of changing my input code, which I'd rather not do.
In the automata app, possibly the last one, I've cleaned up the code somewhat and changed the routine for entering a new code manually (command 'c'), which was always kind of icky, so that now you simply enter a 10 number string of code digits, it will only accept the numbers 0,1,2,3. I also added a new command: 'F' for favorites, which will sequentially plot 11 different codes that I find somewhat interesting. Additionally, just when I thought I was pretty much done with speedups, advice to another coder on the Prog8 section of the discord (by Desertfish), led me to a significant speed up! Plot time is down to 85+ seconds! I have one further addition that I'd like to make to this program....sound. Sound is not my forte. I need to dig in to the relatively new additions for generating sounds on the X16.
Other news. In making the changes mentioned above, I attempted using multidimensional arrays for the first time. While the code compiles, it doesn't work correctly, I later tried a multidimensional array with the compiler under Free Pascal, that generated an error during compile....bad news! Multidimensional arrays are not mandatory though, we get along without them in Prog8.
Also, I have purchased a used copy of J.L.A. van de Snepschuet's book, in which is printed the source code of this compiler/interpreter, back in January. It contains the code for 'for' loops, as an answer to 'student' problems. I added this to my version a few weeks ago....not surprisingly, it didn't work correctly. I moved on to other issues. I finally got around to adding this code to the Free Pascal code so that I could get this working in my version. After initial failure, I finally got it to compile sources using 'for' loops. One disappointing issue, is that using the loop variable inside the loop, seems to short circuit it, causing the loop to terminate after 1 iteration. This is easy enough to work around, but makes using it counterintuitive and why bother, just use 'while' or 'repeat'.
The automata app, as it currently stands, is 547 lines of Pascal code, this compiles to about 2100 lines of p-code which exceeds the original limit and is only 600 shy of the current limit. I have an idea for extending this limit and will probably give it a try in the coming weeks.
funkheld wrote: ↑Fri Mar 01, 2024 9:11 pm
Hi good afternoon.
I think it's wonderful what you've created there.
are you going to expand it?
I also play with the prog8.
Can't you split the Pascal across several banks?
Thanks.
greeting
Thanks! Yes, this should be relatively easy. I haven't done so because I haven't needed to as yet. There will probably be a minor increase in maximum p-code size in the next release, along with the final speed increase. Probably sometime in the next week.
New versions of the compiler, interpreter and a new program, for now I'll call it a launcher. So now we have:
1) p-compile.prg - the p-code compiler.
2) p-interpret.prg - the p-code interpreter.
3) p-run.prg - the p-code launcher.
Now, p-compile will compile the .pas source and if successful, it will write 3 files, .ppc,.pp2 and .pcl. The .ppc & .pp2 files are the p-code and data files, which reside in high ram bank2 (p-code) and bank3 (data), both of which comprise the compiled program, which is executed by p-interpret. The .pcl file is a human readable listing, similar to the one displayed by p-compile, but now you have something to look at...if you want, to try and understand a little more. I would like to add more info to this...someday.
Originally there was only the .ppc & .pcl files, but another change necessitated adding the extra file, that being, the maximum number of p-codes is now 4096, which requires twice that or 8192 bytes of storage for data or paramater space, hence two banks of high ram are now needed. While it's probably possible to fit this into one file, two files was easiest.
Saving all of the p-code & data to disk now allows compiling once and running without re-compiling. I suppose this isn't really that useful, but it provided me with an afternoon's entertainment.
The launcher (p-run) may be loaded and run like any other program and it will prompt for a filename, which will be 'nnnnn.ppc' or the filename can be specified as a command line parameter using this format:
run:rem "file.ppc"
the quotes are required.
In addition to these changes, I have done a bit more optimization work. The compiler actually contains a 'peephole' optimizer, where it examines the current p-code and the previous p-code and certain combinations can be replaced by a different p-code that takes the place of what previously would have been two p-codes. I have known for some time, that string output was very wasteful of p-codes. If you output a 35 character string, it would require 70 p-codes. Why wasn't this included in the peephole optimizer? Well, it is now, so, in the case of the automata program, quite a bit of p-code space was saved, as there are a number of fairly long character strings there! Other optimization has continued in the interpreter, where I have been converting the Prog8 code for the individual p-codes, to hand coded assembly. This is why I prefer to code in high level languages! Assembly is easy and it is hard, for me at least. I went around and around for over a week, reducing execution times, only to find that things that used to work, no longer worked. Sometimes I would find a coding mistake....often I would not. In the end, I realized about a 14% reduction in the plot time of the automata program. Savings will vary, depending on what p-codes and how often thay are used in a program.
Between improvements in Pascal code and improvements in the interpreter, the automata program now plots just a hair over twice as fast as it did originally. It's still slow....but not as slow! I'm almost finished here. I would still like to get records working and for loops too, but after that, if that evers occurs, I think I will call this finished. I don't have the neccessary knowledge nor the patience I think, to turn this into a machine code compiler.
