Hey guys. So, I know I am getting a tish ahead of myself, but well.. in short, I don't want to use ASM for my entire "os" which I HOPE to write for my processor... and I have a decent knowledge of compilers... my question is how do you compile things like variables. I think I can figure out ways to turn higher level code into lower level stuff for ALMOST everything besides variables... I know this is probably not something I will work on any time soon but for now, but I have wondered how this stuff works for a while and I figure this would be a great place to ask.

Hello, sci4me.

The implementation of a 'variable' takes on different forms, depending on the context.

On a small microprocessor like the 6502, room for a stack frame is rather limited and awkward to access
(the 65816 is much more capable in this area), so a typical function parameter is passed in a register
or register pair. This works for most simple tasks, like printing an integer to stdout or similar. Parameters
that won't fit in a register pair may be passed on the stack, or 'by reference', using a register pair as an
address to a parameter block.

It is much more common to treat the 6502's zero-page (addresses $0000 to $00ff) as a 'global' variable
pool, where each resident program (the monitor, interpreter, operating system, editor, user program)
stakes a claim to some of these locations. Failure to cleanly share and cooperate over this resource
results in lock-ups and crashes for the affected program(s), but proper documentation and careful
planning can keep these to a minimum.

A program that resides in RAM and wants to remain self-contained may reserve an area within itself
for variable storage, but this is a bit slower than zero-page, and simply won't work in the case of
pointers, unless self-modification is employed.

Programs that wish to use recursion will have to make very frugal use of the system stack, implement
their own software stack, or figure out a way to solve the problem using iteration.

These are rather general statements, but should give you an idea of what is involved. Perhaps others
could link you to some example outputs from their own libraries, but my VTL02 source shows how this
can be done in zero-page for a program that pretty much has complete control of the machine. VTL02
grabs 128-bytes of zero-page ($0080 to $00ff) for its own use, and ignores the fact that Applesoft and
DOS will be clobbered, since it does not depend on them for anything, and assumes that it will remain in
full control of the machine until the next RESET. It does have to cooperate with the monitor for character
input and output, so it knows to stay away from the zero-page variables used by these routines to keep
track of things like the current row and column of the cursor, the display height and width, the pointers
used for scrolling the text display, and (outside of zero-page) the text display RAM itself.

Happy programming!

Mike

Be sure to read the topic "introducing minimOS" which kind of turned into a discussion on whether you even need an OS, and how various functions that are often associated with an OS can be taken care of by a kernel that's not really an OS.


The way I did variables in my '816 Forth kernel was that they basically return a constant that is the address of the data space. In most cases, that data space is mixed in with the code space, taking the next available bytes at compile time, however many you assign to the variable. (That's if you're compiling code into RAM. If you're metacompiling code to go into ROM, obviously the variable data space will have to be separate so it can be in RAM where the processor can write to it. For that, two pointers are kept, one for what address is available next in ROM for code, called DP for "dictionary pointer," and returned by the Forth word HERE, and another for what address is available next in RAM for variables, returned by the Forth word THERE.) You could make the constant point to a data space in ZP too if you like. As for the pointers Mike mentioned, in Forth everything goes through the data stack anyway, and that's in ZP (separate from the hardware stack in page 1 which Forth uses as the return stack), so you get all the ZP addressing modes. That plus other simple tools allow you to define new data structure types for example where they do one action at compile time and another one at run time, and you can have any number of levels of indirection with processing in between if that's what you want. It even allowed for object-oriented programming (OOP) before it was even called that.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Well, looks like this is going to be quite the project. The way I see it, i'll just read over this thread and figure out some way to implement it. As far as OOP goes, I would LOVE to have a language that is OOP and compiles to run on my processor. Then I could really get into OS dev. Because the way I see it, it would be easier for me to use a language similar to c++ with inline ASM than just ASM... of course I am getting ahead of myself but it cant hurt to learn earlier than needed. As far as whether I really need an os, this project is really just for general usage / fun and not any specific use cases, so I intend to have a unix/linux-esque type system (referring to the file system mainly for now..) But, whether I get that far or not will depend on a lot of things I suppose.

You can use assembly and still raise the level of the language well above what people normally think of with assembly, by using macros to make nestable program structures, and data structures too. I have an article on the program structures at http://wilsonminesco.com/StructureMacros/index.html with source code for 65c02 (with the C32 assembler) and PIC16. You can have IF...ELSE...END_IF, BEGIN...UNTIL, BEGIN...WHILE...REPEAT, BEGIN...AGAIN, FOR...NEXT, CASE statements, and whatever else you want to add. And although you become more productive and get better control of the project and produce more bug-free and maintainable code, there's usually no penalty in either memory taken or run speed. They're mostly nestable too. Anton Treuenfels implemented these in his HXA assembler, and BitWise here also on the forum has his AS65 assembler which has similar capabilities built in with no macros needed.

As they say, "a little assembly goes a long ways," and you don't need to do whole applications in assembly; but the structure macros definitely take a lot of pain out of assembly, with no resulting penalties.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Well, several things.

Languages, grammars, lexers, parsers, compilers, that's a completely different ballywick. Memory allocation, call sequences, stack frames, that's another. The 6502 is actually a pretty lousy target for what many consider a high level language today. Something like C is expensive to implement, for example.

An OOP language is not recommended simply because OOP is really (really) expensive on memory. On modern computers, memory is beyond cheap. On a 6502, 64K runs out really quick. There's a reason none of the operating environments for 6502 in particular, but 8 bits in general, are not written in high level languages. Mind, the singular exception to this are the Forth's, which are mostly written in high level Forth, but their core is in assembly.

However, that all said, you can look at higher level language support in your CPU, and punt on the 6502 completely. There are Forth chips that implement the core inner interpreter of Forth in silicon. You could look at things like the UCSD P-Machine, which compiles to a "Pseudo Machine", which happens to be a stack based architecture. The Lisp Machines had custom hardware specifically designed to better support Lisp runtime environments. A popular Lisp implementation called CLISP has its own P-Code that it compiles down in to.

Of course, there is also the Java Virtual Machine (JVM). Crawl around the internets, and you'll find they've implemented JVMs on some shockingly small hardware, and there have been efforts to get it to run on custom hardware.

So, anyway, the point is that you can actually implement some high level instructions in your CPU to make high level language more readily supported.

Exactly Any like you said I have the freedom to as much ram as I want really.. considering i'm designing everything. I mean my processor is 32 bit so its a significant step up from a 6502 but the instruction set, registers, etc. is inspired by the 6502 and by my own mind. As far as OOP goes, thats true. If I do end up getting that far though, i'll have GC. But, realistically, chances are I wont get that far. But, I still hope to and intend to eventually.

I'm wondering how it's possible to know almost everything about compilers except variables. I recommend reading this book a few times:
http://www.amazon.com/Retargetable-Comp ... ref=sr_1_1

And, if you haven't already done so, the standard text on compilers, the Dragon Book: http://www.amazon.com/Compilers-Princip ... 0321486811

Okay, I said that very incorrectly lol... I know how to write one but as far as actually compiling high level stuff to asm, the code generation.. I think i could do some of it but obviously not nearly all...

The first book is still a good recommendation. It has the source code for an entire compiler, and explains everything from beginning to end. You can even take their code, and just modify the CPU specific parts. Of course, it's only C, not C++, but I wouldn't touch C++ unless you first have a working C compiler. C++ is a magnitude harder to do properly.

For an OS, it's better to use C anyway.

David Schmenk has actually implemented a JVM for the 6502 (actually, the Apple II) - that's both horrifyingly impressive and impressively horrifying

He also has something called PLASMA ("Proto Language ASseMbler for Apple); at a cursory glance this looks like it might be a viable high(er)-level programming environment for the 6502.

Then again... FORTH has already been mentioned, and may well be the best compromise between programmer productivity and efficient use of the resources of a 6502.

A JVM for the 6502. That sure is something... I will definitely check out that book though. Thanks for the help guys!

This is like saying, "I know how to drive a car, but what are the foot pedals for?"

Toshi

I meant like how to write a lexer and a parser, I didn't mean to make it seem like I know codegen.

Make sure you study more processors than just the 6502. For the number of registers and widths you are looking at, the 68000 comes to mind.