Need list of features for PBASIC emulator.
 

I'm currently working on my OI/RC emulator for testing code with, and I'm wondering how much of the PBASIC language people actually use. I just ask because I don't want to spend hours coding support for an obscure command that nobody is using. On the other hand, even if only one person is using it, I would be happy to add support.

Here is the list of the obvious ones I have come up with so far:
+,-,*,/, =
and, or
&, |, ~, ^
Min, Max
Serin, Serout
VAR, CON
Output (for LEDs)
store, load
goto, labels
if

Other ones I'm not sure about (I haven't used them, but I can see where some teams might):
Lookup, Lookdown
Trig functions
for loops

Anyway, that's all I've been able to come up with so far. Others?

put/get
write
gosub (I've never personally been organized enough to break my pbasic into subrotines, but I have seen robot code that does)

That's all I can think of now. BTW, good luck with your emulator.

Stephen

P.S just in case it slipped your mind (it probably didn't, but just making sure), make sure in your VAR command you have the functionality to go var_name.bit0, etc.

<<>>
 

I like using << and >>

aand make sure it truncates the numbers "correctly" we don't want any emulator that is better at math than the real thing...

lol

easy way i've found to truncate numbers in C++ like you do in PBASIC. declare a 'double' (probably works with 'float' too) variable which takes in the number, then just declare an 'int' variable, whcih then assumes the value of the double. like this...

that would print out a 5. you will get a warning, but that's the best way i've found to truncate the numbers in C++. i'm sure there's some class that does it better, but i've yet to find it.

type casting
 

How about just using type casting instead. For example

Stephen

word up homies
 

don't use any floats or doubles anywhere in the program. at all. not even one. the 2sx doesn't have the foggiest of what a decimal point was. What i was trying to say is that although an int will truncate correctly when all is said and told, the math inbetween will not. for example, in pbasic, 5/2*2=4, not 5. C++ will do all the math out with some ungodly precision and then truncate. you may need to change x=x/2*2 to x=x/2; x=x*2.
Also, declaring it as an unsigned might be better, so that you automatically get wrapping up top and below, ie 267 doesnt exist and neither does -6. don't know how to handle the 255 thing with out anal checking in the code.

BTW - i have used words as well (hence the title of the post) and have accessed specific bits in a byte. ie

var variable= 126
variable.bit5=1

good luck getting that to work. I think you'll need to use bit masking or some other craziness

Thanks for all the suggestions! PBASIC is not overly complicated (no order of operations!), so none of it should be too technically difficult. As for the 255 thing, I'm not going to check it. After all, if your code ends up producing 255's, you probably want to know! The way I've planned out the tokenizer, expressions such as x=5*y/z will be evaluated in two steps, so truncating shouldn't be an issue. The way I'm planning on doing individual bit assignments is to use different algorithms for 1 and 0. For setting a bit to 1, I will use | with everything set to 0's except the bit that needs setting. For clearing a bit, I will use & with a mask of all 1's except for the bit that needs clearing.

One more questions: has anyone ever had a need to access a specific nibble in a byte, or a specific byte in word? Is this even possible?

from the manual (it would be var_name.<entry from below>)
i don't think it'd ever be nescasary to access a single byte in a word in the robot code since inputs and outputs are limited to bytes. maybe as a clever optimization or something, though.

Stephen

variable renaming
lookup/lookdown
gosub

That's all I used that wasn't in your list...

Here's our code that I created. The grabber subroutine is totally inefficent code-wise, but it works flawlessly. Our grabber is totally automated with 2 rocker switches... Also the code meshes well....

Our code.

By renaming, I assume you mean:
newVarName VAR oldVarName

If not, please explain as I just finished coding the support for the above type of operation (including .bitX, .nibX, .byteX, etc) and would like to be finished with this section ASAP because everything else depends on it.

My brain hurts from all the binary math, but other than that, everything seems to be working!

Yup... that's exactly what I mean... Thanks!

Anyone use BRANCH? This will be in there for sure (now that I know about it, I'm definately going to use it next year), but I'm trying to prioritize.

BRANCH? never heard of it. of course, i've only used the easy commands, cause i didn't know anything this year :D.

Can you elaborate on the architecture of this emulator? Is it going to interpret object code or is it going to parse PBASIC code?

Basically, it's like a C switch statement. The syntax is:
Then, it will branch to the label specified in the list above. For example,
could be used to replace

I'm not quite sure what you mean by object code, but basically it will let you take a PBASIC program and "run" it on a regular computer, thus letting you see what it does without the need for a $1200 OI/RC pair, so I guess it would fall under the "parse PBASIC" category.

I make frequent use of looking at bits in a byte or word, but i have never needed to look at the nibble. now for thi biggest feature -- communicate with the serial port and control the bot!

Recently, I've worked on an expression evaluator in C++. It would solve mathematical expressions in the correct order of operations. For example, I could input a string like "2*(5+4)^(1/2)" and it would output "6". If you would like to collaborate, I would be glad to help. If I can get the source code to my program (I worked on it in school and we, the senior class, are pretty much done, so I haven't showed up in a while). then I can provide you with my engine for parsing strings.

my old team did, as well as multiple program slots.

debug would be nice, although probably not necessary.

one that i just thought of from seeing a picture of joe...

DATA and READ. those are the commands that use the eeprom in a bsx stamp. i'm sure joe knows this well by now :D. anyways, if any teams do use this for something valid, i think you may want to include functionality for those commands. an easy way would be to make an array for all the eeprom spots requested, and then just have the READ function call a certain array index, and you have your data. sounds simple in my head, probably isn't in real life :p.

Multiple program slots of course implies the RUN command

I'll probably do it as a linked list, just because it is more dynamic in size, but it shouldn't be too bad. This is the setup I have for the variables, and it's working very well (I've posted this part on my website, if you're interested).

From what I've been hearing, every PBASIC command has been used for FIRST (with the exception of some of the pin-based I/O), so this project just became a whole lot bigger than I expected. But that's what summers are for! (I just finished school about 10 min ago, and can't wait to get started on something other than English papers). Look for a mostly finished product by the end of June (hopefully).

one possible problem about running the eeprom as a linked list...

eeprom is semi random access. you can jump from anywhere to anywhere in it, so unless you like having lot's of loops, i'd think your better off with an array. of course, as long as it doesn't take that long to run through a loop, a linked list is fine. just try to keep the list down in size if possible.

Ahh... the age old question: optimize for memory, disk space, or performance? I might write a class that auto-resizes the array when there gets to be too many elements, or I might just make an array big enough to map the entire eeprom to even though it wastes a lot of memory.

well, something else which would be slightly harder, yet still use an array, and not waste any space is as follows...

to enter anything into the eeprom, you use the DATA command. so, before you run the entire code, run though once, checking for DATA commands. after every DATA command, count the number of commas (indicating how many spaces are needed in the eeprom), or something like that to determine the amount of eeprom needed (or in your case, the length of the array). not that complicated, and just a little harder. also, this way, if you don't use the DATA command, you waste no memory on the eeprom array. win/win situation for all. now, just to program that... :D

in case you guys didn't notice, but a stamps rom is 2k... My computer has roughly 192000 times that much in ram... i think optimizations should be done not for speed (1ghz vs 40khz) disk space (20gb vs 2kb) or ram (384mb vs 32b) but for workablility (currently does not run PBASIC vs currently does run PBASIC) good luck though.

A 2k element array wouldn't be that bad (I've done multi-million-element), but its the principle of wasting RAM unnecesarily. I gave up on conserving disk space long ago, but I'd like to try (for the sake of good software engineering) to find a balance for RAM and speed. As for the speed, a 2sx is 50Mhz, which makes me a little concerned about speed on older computers (especially laptops) due the increased overheard with translating the strings, providing a UI, and Windows hogging a big chunck of it.

I thought about just making the array big enough for the DATA commands, but then I'd still have to resize the array after a WRITE command, as this can be used to write data to a new location on the fly. Using a self-resizing array would still require some kind of indexing because there is nothing saying that DATA has to start at location 1 in eeprom. Either I'd have to use an array the size of the whole eeprom(at which point I may as well make my array 2k elements) to do mappings to my little array, or store the location with the data, at which point I'd have to loop through anyway. And that gets me thinking of my friend the binary search tree...

Anyway, as of right now, it loops through and finds all VAR/CON statements (since PBASIC doesn't care where you put them), so adding the DATA directive to the list should be easy.

heh, this gets so much more complicated than it has to be... :D

Still....
 

I still think it would be easier and perhaps better to just instantiate the whole array. You are making an emulator, so you should be true to the original flaws. That is why you must not use floats, you must maintain that original inability to do order of opps and so forth. Besides, simply writing char eeprom[2k] is alot simpler to debug later...

For now, I agree, and this is the quick-and-dirty implementation I have right now. If I become un-lazy in the next few weeks, I may implement something a little more elegant. Probably not, though. Anyway, VAR, CON, and DATA are all working now, and I'm putting the finishing touches on my expression and comparison evaluators. From there, the rest is just details.

BTW, parenthesis suck.

Well, I finished the expression evaluator tonight. Currently it supports +,-,*,/,MAX, MIN, (). It even gives the correctly incorrect answers! The parenthesis implementation aint pretty, but it seems to work, so I'm not going to mess with it. To be added whenever I have a spare minute: <<, >>, &, |, ^, ~. I gave these a slightly lower priority because I don't see them as being as common. Anyway, it should be smooth sailing from here as the only other big concept I need to implement is goto.

Oh yeah, I decided not to take my laptop to England, so I'll be taking a two-week break from this project, so don't expect anything usable until mid-July.

Well, if you are going, i am sure the good people of the forums would love to give it a good alpha testing... If you post the code i would appreciate it greatly, and you might just come back and have those opperators done for you...
Have fun in England

Good idea. It's up at http://FIRSTprograms.tripod.com. Check out the readme for some of the little quircks and caveats as well as a quick overview of some of the more complex and obfuscated sections. I'll be checking my email (and therefore these forums) every few days or whenever I find an internet cafe, so post back with and questions or comments, and I'll do my best to answer them. Remeber that after tomorrow I won't have the code with me, so post the actual code of any sections you have ?'s about.

ahh, what do you get for not reading the boards in a long time? Bringing topics back from the dead ;)

This is definately an important consideration. Kudos to you. ;) Everyone here should read this article from today's Slashdot: http://msnbc.com/news/768401.asp.
It basically describes the problem of bad/rushed programming, its effects, and why in terms of the long run, more time should be spent concentrating on efficiency and structure rather than the "it's quick and dirty, but it works" method. As the quote from the article says, it's not really about processing power or memory... rather it's about the fact that because programs have become so complex, more time is needed think about how the program will work and design it to work. Otherwise, well we've all seen the Blue Screen.

As for the actual emulator dilemma, since an array is the better way to go in terms of usability, but a linked list is better in terms of efficient memory management, how about you reach a compromise? How about you make an array of pointers, making them only point to information as needed?

um, dan, i believe that an array is actually just a long thing of pointers, each pointing to a specific location in the memory, in which data of a certain type can be found. so making an array of pointers would really be completely pointless (yes, we all laugh at my clever little joke :p).

Assuming you're talking about the C programming language (and probably several others actually), an array isn't just a list of pointers. Instead an array is simply a single pointer. When you combine a pointer with an offset (ie the array index), you can point to any specific value in the array. Now as to, arrays of pointers, they do have a use. Unfortunately in this case, using an array of pointers wouldn't help. On most systems, integers and pointers are the same size (in bits). Therefore an array of 2000 integers takes up the same amount of space as 2000 pointers. Given that there needs to be space to allocate what the pointers are pointing too, it's less efficient to do the array.

As far as whether an array of 2000 integers takes up a lot of space, I'd have to say it doesn't as it's merely 8 kilobytes of space which is not much at all compared to what computers support.

For those interested in an emulator, look here:
http://www.chiefdelphi.com/forums/sh...&threadid=4720

Matt