Not really, all perfectly doable with PICAXE BASIC but an inline assembler would be nice“A simple "push variables' at the start and "pop" variables at the end.”
Ah ha! Not just me pining for an inline assembler.
so it does not completely wanish..
But that's like real *work*Write a TUTORIAL and post it somewhere safe and accessible.
From Wikipedia:At first I was thinking that perhaps the way to make my code more readable and reusable would be to use parameters and local variables in my pseudo code and then sort out the stack-pushing and variable allocation when I put all the required routines into my main program. Really I would be acting like a compiler, or a source translator, translating from my pseudo code into PICAXE BASIC. But then I started to think about how this process could be automated...
Also, from Wikipedia:BASIC is a family of general-purpose, high-level programming languages whose design philosophy emphasizes ease of use - the name is an acronym from Beginner's All-purpose Symbolic Instruction Code. The original Dartmouth BASIC was designed in 1964...
Why so long between BASIC and Simula/Smalltalk? RAM... Random Access Memory is the enabler of language evolution. The concept of PUBLIC, PRIVATE, and STATIC, locks, semaphores, attributes are all RAM-hungry concepts. Consider a BASIC integer: In the PICAXE it is either a byte or a double-byte (word). Essentially, this is a basic idea that for the beginner in the language is often a stumbling block. But, in this forum, I have seen some very cleaver 32-bit routines which are not for the faint-of-heart. I will go out on a ledge and state that in-my-opinion, language advancement from concept to product is tied to RAM availabilities of the processor.Simula (1967) is generally accepted as the first language to have the primary features of an object-oriented language. It was created for making simulation programs, in which what came to be called objects were the most important information representation. Smalltalk (1972 to 1980) is arguably the canonical example, and the one with which much of the theory of object-oriented programming was developed.
I've included the push/pop within the sub. Always using a dedicated area of scratchpad (I'm using 28X2 and 40X2 chips) and planning the program flow to *not* re-enter the sub, I have sufficient space to push as many variables as needed. Most recently, I used this to read a block of data from FRAM (via I2C) and write it to a uM-FPU floating point chip (also via I2C). I think the new uM-FPU64 has I2C master capabilities, so the newer FPU may be able read the data directly from the FRAM - one more thing on my to do list...One quick and easy thing I do when running out of variables and want locals is to simply write two subroutines. One to push all (often just the first five or so) variables and another to pop them.
These get called at the start and end of each subroutine respectively.
Symbol defs can be placed anywhere in code, so each subroutine can have its own variables and documented variable use.
With a little discipline you end up with portable subroutines but with a slight speed overhead.
I think, so I am... err, another post, me thinks. I can not argue that, it is hypothetical. But a preprocessor cannot make any particular PICAXE a superstar because the PICAXE has RevEd firmware in the chip. The chip architecture and limited resources can only provide so much Ump and there is nothing a preprocessor can do to enhance that fact.<...>
I think that the inclusion of a preprocessor would help make PicAxe code more maintainable, and be completely ignorable by most folks.
Oh, it would not have mattered, I'm having one of my devil's advocate days!I should have made myself more clear.
<...>
Borland's Turbo Basic (DOS based, still available as Power Basic now that Borland is gone) compiled to native 80x86 code and ran incredibly fast. If Rev Ed should create something with similar abilities, they would probably have a fantastic commercial compiler.If you want to see the epitome of BASIC, have a look at VAX BASIC from DEC. Both long gone now, but in my humble opinion there never was a better language created.
Not sure I agree. Yes, it has deviated hither and yon, but the original topic was the using PICAXE BASIC to write maintainable code. Others have merely suggested alternative ways to skin that cat by changing the PICAXE BASIC programming model or looking at other alternatives. Open discussion in it's best and most rewarding form is organic and ... open.All very interesting, but this thread has gone way off topic. Just sayin' ...
I remember it well.Borland's Turbo Basic (DOS based, still available as Power Basic now that Borland is gone) compiled to native 80x86 code and ran incredibly fast. If Rev Ed should create something with similar abilities, they would probably have a fantastic commercial compiler.
Good for youThat being said, I have not encountered a problem with a program that is suitable for a PICAXE that has challenged me with confined resources. I generally complete my code and have significant code and variable space remaining.
May I suggest that we are not discussing a microprocessor with external RAM & ROM, but a micro controller with internal RAM & EEPROM. It is true that there are compilers for uC that will provide public and private variables and true functions, but these are "real compilers.". The PICAXE compiler is not the same kind of compiler because it compiles the source to a pre-digested code that is later interpreted by the firmware in the PICAXE. Unfortunately, the firmware uses uC chip resources and provides a quasi-virtual environment for your code that is, your code is isolated and abstracted from the hardware.What would be needed is to parse the pseudo code 'language', keep track of the scope of each variable so that we know when it is no longer needed and copy parameters and results to and from the stack (or block of variables, depending on the implementation). The simplest approach would be to use PICAXE BASIC with a few extra features, as this would make the rest of the translation trivial. Of course the generated code would not be as efficient or tidy as that produced directly by a programmer, but that's the trade-off for making it easier to write complex programs.
What I was (vaguely) suggesting was a meta-language which would be converted into straight PICAXE BASIC by a source translator. The meta-language I suggested could, for simplicity, consist of a limited number of extensions to PICAXE BASIC.But, because PICAXE is interpreted BASIC, some of your very good suggestions would require the consumption of significant chip RAM and require major changes in firmware to support the concepts. This is not to say such concepts do not have value, but as you know you can migrate to a true compiler and language that supports libraries and variable encapsulation, variable passing to sub and functions, etc.
Never give up!<...>
By the way, I would be happy to use C (even though I never use C), but that would require me to get a PIC programmer AND completely redesign my hardware, which I really don't want to do, and let's face it, would kind of be admitting defeat ;-)
OK, I'm beginning to get your drift, I think. Probably what you are wanting is macro expansion with a PE scripting capability. Most scripting languages have the ability to parse text strings and intrinsically have internal variables which permit the ability to store, transform, and manipulate strings. It is a tall order, but I understand your comments of a "pre-processor" better now.What I was (vaguely) suggesting was a meta-language which would be converted into straight PICAXE BASIC by a source translator. The meta-language I suggested could, for simplicity, consist of a limited number of extensions to PICAXE BASIC.
Unfortunately, the firmware "wiring" inside the PICAXE currently cannot support scoped variables. It is not a PE compiler problem but an architectural issue with limited resources and interpreted BASIC code. Undoubtedly, the day will come when uC components will have sufficient resources for RevEd to perform such magic, but we are not there yet with the current instruction set that is supported within the PICAXE firmware. RevEd "may" be able to pull off such magic with a minimal instruction set, but what fun would that be?<...> And use it to generate RevEd BASIC code. It will probably be horrible inefficient and slow on the PickAxe, but by golly, it will have subroutines with scope!
Ha ha. I hate to let the machines beat me.Never give up!
Hmm, not really. What I was suggesting is really very much like what KeithRB has suggested, except he is talking about converting C into RevEd BASIC. I was talking about allowing a few extra language features (think of it as a dialect of PIC BASIC) such as scoped variables and parameters to subroutines, which would be converted into standard RevEd BASIC by a source translator. This 'pre-processor' would work out how to allocate the required variables in the limited PIC memory, and take care of copying parameter values around. The result would be ordinary PICAXE BASIC code which has been generated by the source translator from your own code.More than a pre-processor, I think you are driving me to think that you want a self-documenting report coming out of PE? You do not want to change the language and you do not want to change the firmware, you just want a more productive environment. Is this correct?