Thank you for your reply, Garth.
GARTHWILSON wrote:
I'm not aware of any such tutorial, and the macro language sections of assemblers' manuals only give rudimentary examples.
Thank you for that information. Most of my programming knowledge I learned from experienced people anyway - not from books.
GARTHWILSON wrote:
(I can still imagine the macro language being made more intelligent though, to do even more, like to parse FORTRAN-like lines and spit out good assembly language.)
That would be very interesting for me.
GARTHWILSON wrote:
The best you'll be able to do without a stack is have variables in memory that are only used by the particularly routine, non-reëntrantly (which also mean non-recursively). In simple applications, you might do fine. Otherwise, it's not a very good use of memory, and it's easy to tie yourself up in knots, especially if you try to have multiple routines use the same variable addresses to save memory with the idea that those routines won't ever need the variables at the same time. Almost inevitably, it eventually leads to trouble. Been there, done that (in my greener years).
Thanks. I understand that. I think the new llvm-mos does this management of variable adresses, and old Fortran compilers probably too.
I want to avoid doing this manually, and I think a compiler can do that for me.
GARTHWILSON wrote:
Stacks really do solve a lot of problems, and in the case of structure macros, where you want to have nested structures of the same kind and have all the branching go to the right places, some sort of stack is mandatory (although in the assembly-language macros, it's done by the assembler during assembly time, not on the target computer at run time).
Yes, I understand that now.
GARTHWILSON wrote:
Perhaps you got a bad introduction somewhere along the line that got you thinking that stacks are mysterious and complicated.
No, not at all. I am used to program with stacks.
I am not used to a stack that is only 1/256th of the computers memory and a CPU that has no stack relative adressing modes.
GARTHWILSON wrote:
(I've brought a lot of products to market using PIC16C and PIC16F microcontrollers (and implemented my structure macros for them too), and their super-simple processor is very limited, and stacks do become cumbersome there, and in fact the programmer is not even allowed access to the hardware stack. That's not the case with the 6502.)
I always wondered how someone could implement a C compiler on such processors (or even PIC12, PIC10). But such compilers exists. They are using a "compiled stack" as Microchip calles it.
GARTHWILSON wrote:
Since you're concerned about speed penalty: ADC $105,X in the hardware stack area for example takes the same number of cycles as ADC $105;
Yes, if I want to use a small stack.
GARTHWILSON wrote:
and in ZP, ADC ZP,X takes only one more cycle than ADC <ZP>.
That will work only in the zeropage. It is not indirect, if I am correct.
GARTHWILSON wrote:
You do have to set the X at the beginning of the routine, but then you can access the various local variables by changing only the base address which is part of the instruction, with no need to keep changing X.
That is a very interesting trick, if I want to access the hardware stack or any stack with a size of 256.
This combined with self modifying code could be interesting.
GARTHWILSON wrote:
If you're concerned about speed though, it may be time to abandon the NMOS 6502,
I want to figure out, how people in the old days programmed for the NMOS 6502.
GARTHWILSON wrote:
There's an undercurrent I'm sensing that I might come back to write about, if I can figure out how, regarding control and where the details are handled in the various levels of language.
Sounds great to me.
I am already reading
http://wilsonminesco.com/links.html and I am getting good information there.
Login
Register
FAQ
Search
The 802, as far as I know, was never part of any OEM design—I seem to recall WDC originally intended it to be an upgrade path for Apple ][ users.
