No love for FORTRAN?

[GARTHWILSON]

I started writing a reply two weeks ago, set it aside before I finished it, then forgot about it, then lost it, which might be just as well, as I remember getting kind of tunnel-visioned.

Hermes wrote:

Thank you very much Garth Wilson for your link about structured macros.
I think, this is exactly what I was searching for.
This is amazing!

You're welcome.  BTW, it's "stucture [no 'd'] macros," because the macros themselves are not particularly structured, but rather, they are used to form program flow control structures when you invoke them.  Internally they may or may not particularly appear very structured.

Quote:

I never could find a good tutorial about advanced macro techniques.

I'm not aware of any such tutorial, and the macro language sections of assemblers' manuals only give rudimentary examples.  I guess the writers of the manuals hope that from there you'll either see the possibilities and take off after they've given you the spark, or hope you already have experience from other assemblers.  Unfortunately there are a lot of bad implementation examples out in the wild that dissuade people from even trying macros, and a lot of nay-saying from people who haven't thought through the possibilities afforded by conditional assembly in the macro definition.  A fair amount of intelligence can be built into the macro definition by using conditional assembly, so you can write your macros to produce the most efficient code possible for each invocation's situation.  (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.)

Quote:

And I have some clue how to pass parameters without a stack and maybe how to have local variables without stack. I need to learn more about that.

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 means 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).

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).  These things are addressed in the treatise on 6502 stacks ("stacks" plural, not just the page-1 hardware stack) at http://wilsonminesco.com/stacks/ .  Perhaps you got a bad introduction somewhere along the line that got you thinking that stacks are mysterious and complicated.  They're not—at least not on the 6502.  (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.)

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; and in ZP, ADC ZP,X takes only one more cycle than ADC <ZP>.  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.  If you're concerned about speed though, it may be time to abandon the NMOS 6502, since the CMOS is several times as fast and has more instructions and addressing modes.  (I realize that may not be an option if you're dealing with a C64.)

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.

[commodorejohn]

(Fun^H^H^H challenge - implement stacks with the use of ordinary arrays!)

[BigDumbDinosaur]

commodorejohn wrote:

(Fun^H^H^H challenge - implement stacks with the use of ordinary arrays!)

Commodore did that in BASIC 7.0 running on the C-128.  There is a run-time stack at $00800-$009FF, which is where info about active DO and FOR loops, and GOSUB returns is kept. The pointer into the stack is at $7E-$7F.  Since stack elements are accessed with (<zp>),Y addressing, performance takes a hit, a situation exacerbated by the need to perform pointer arithmetic as entries are pushed and pulled.  The use of a run-time stack was a big part of what helped to make BASIC 7.0 the slowest BASIC ever published by Commodore.

[BigDumbDinosaur]

GARTHWILSON wrote:

...If you're concerned about speed though, it may be time to abandon the NMOS 6502, since the CMOS is several times as fast and has more instructions and addressing modes.  (I realize that may not be an option if you're dealing with a C64.)

And if switching to the 65C02 is an option, then switching to the 65C816 would make even more sense, since it handles the stack much more elegantly than does the C02.

[fachat]

BigDumbDinosaur wrote:

GARTHWILSON wrote:

...If you're concerned about speed though, it may be time to abandon the NMOS 6502, since the CMOS is several times as fast and has more instructions and addressing modes.  (I realize that may not be an option if you're dealing with a C64.)

And if switching to the 65C02 is an option, then switching to the 65C816 would make even more sense, since it handles the stack much more elegantly than does the C02.

Just note that going to higher speeds or the 65816 doesn't work just by replacing the CPU ....
The system needs to be designed for that.

André

[GARTHWILSON]

fachat wrote:

Just note that going to higher speeds or the 65816 doesn't work just by replacing the CPU ....
The system needs to be designed for that.

Daryl has a design for a 65802 module to drop into an '02 socket.  AFAIK, it's not proven yet, but if someone wants to take up its making and distribution, I know many here (including me) would line up to buy one or more of them.
http://sbc.rictor.org/support/conv.html
The '802 is an '816 made to drop into a 6502 socket.  Obviously then it won't have access to memory outside of bank 0 (meaning it only addresses 64KB or memory map), and won't have the '816-specific signals.

[Hermes]

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.

[Hermes]

BigDumbDinosaur wrote:

Commodore did that in BASIC 7.0 running on the C-128.  There is a run-time stack at $00800-$009FF, which is where info about active DO and FOR loops, and GOSUB returns is kept. The pointer into the stack is at $7E-$7F.  Since stack elements are accessed with (<zp>),Y addressing, performance takes a hit, a situation exacerbated by the need to perform pointer arithmetic as entries are pushed and pulled.  The use of a run-time stack was a big part of what helped to make BASIC 7.0 the slowest BASIC ever published by Commodore.

This is exactly what I want to avoid.

[Hermes]

GARTHWILSON wrote:

Daryl has a design for a 65802 module to drop into an '02 socket.  AFAIK, it's not proven yet, but if someone wants to take up its making and distribution, I know many here (including me) would line up to buy one or more of them.
http://sbc.rictor.org/support/conv.html
The '802 is an '816 made to drop into a 6502 socket.  Obviously then it won't have access to memory outside of bank 0 (meaning it only addresses 64KB or memory map), and won't have the '816-specific signals.

Is there any '802 available? I have never seen any offer on the internet. And I don't know any machine which used it.

[barrym95838]

I had an '802 I bought from Jameco around 1989. It played nicely in my Apple ][+, but there was obviously zero firmware support for its enhanced features, and I lost track of it and the computer during a time when neither seemed to have any monetary or nostalgic value. My life has been filled with dozens of gadgets and vehicles which suffered the same fate. Many have been lost, and many are still stuffed in my nightmare of an attic. And a couple are still languishing in my nightmare of a back yard.

[resman]

There is a guy in the Apple II community that was able to procure a handful of NOS '802s. I put one in my overclocked Apple IIc+, and makes a great portable development platform for PLASMA (along with a 1 MB RAM drive). However, it wasn't cheap. There is possibly the option of an adapter board for an '816 but my understanding is that there may be some timing issues with designs expecting the NMOS 6502. I do use a Transwarp accelerator in a Platinum IIe that allows an '816 to be directly plugged into it. Again, not exactly cheap. If you were interested in exploring the 16 bit options of the '816/'802, I would suggest finding an inexpensive Apple IIgs and pretending it was an Apple IIe with a nice RAM drive. That way you could explore all options from a baseline 6502 to an extended memory '816. This is, in fact, the approach I took with PLASMA. Although I never plan on implementing a fully extended memory '816 VM, I did write a VM that takes advantage of the '802/'816 in an Apple //e 128K banked memory architecture.

[BigDumbDinosaur]

Hermes wrote:

Is there any '802 available? I have never seen any offer on the internet. And I don't know any machine which used it.

The 65C802 is a pretty rare animal these days, nearly as scarce as unicorns...or honest politicians.    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.

Daryl’s replacement module almost does in discrete parts what the 802 did internally.  I say “almost” because it cannot implement SOB (set overflow not), which the real 802 had—that input doesn’t exist on the 65C816.   In practice, that isn’t likely to be a show-stopper, as outside of some Commodore floppy disk drives, SOB is/was seldom used.  Even the late Chuck Peddle once said he wasn’t sure why that was part of the 6502 design. 

If I were going to build the module, I would redo it to use 1G logic.  Also, I would arrange it so the 816’s BE input could be jumper-connected to pin 36 for use in a system designed originally for the WDC 65C02.  I’d do a similar thing with the 816’s VPB output (pin 1, which is ground on the 6502 and non-WDC versions of the 65C02), again for upgrading a system running a WDC C02.

That said, it’s all academic for me, as I can’t see nearly well enough to handle 1G and QFP packages. 

[GARTHWILSON]

Hermes wrote:

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.

What do you want to do that requires such a large stack?  From the stacks treatise's "Enough stack space?" page at http://wilsonminesco.com/stacks/enoughstackspace.html :

• A common criticism of the 6502 is that the stack space is so limiting (or at least perceived to be).  A few higher-level languages (notoriously Pascal) do put very large pieces of data and even entire functions and procedures on the stack instead of just their addresses.  For most programming though, the 6502's stack is much roomier than you'll need for most things, especially assembly language.  When you know you're accessing the stacks constantly but don't know what the maximum depth is you're using, the tendency is to go overboard and keep upping your estimate, "just to be sure."
  
  I did this for years myself, and finally decided to do some tests to find out.  I filled the 6502 stack area with a constant value (maybe it was 00—I don't remember), ran a heavy-ish application with all the interrupts going too, did compiling, assembling, and interpreting while running other things in the background on interrupts, and after a while looked to see how much of the stack area had been written on.  It wasn't really much—less than 20% of each of page 1 (return stack) and page 0 (data stack).  This was in Forth, which makes heavy use of the stacks.  The IRQ interrupt handlers were in Forth too, although the software RTC (run off a timer on NMI) was in assembly language.

Also, as it says in the virtual-stacks page at http://wilsonminesco.com/stacks/virtualstacks.html, although you might be worried about losing the use of X when it's constantly used for stack indexing, it turns out that when you're doing a ZP data stack, X seldom needs to be saved and used for anything other than the stack pointer; so you don't need to lament the loss of your X.  And yes, the stack takes precious ZP space; but it greatly reduces the need for so many ZP variables.

Quote:

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.

There is also the abs,X addressing mode, which takes one more byte and one more cycle.  True, there is no (abs,X) or (abs),Y addressing mode, which is one reason it works better to have a data stack in ZP, if some of the data-stack cells will be addresses.  (There is a JMP (abs), with no indexing, and the 65C02 also has JMP (abs,X).)

[johnwbyrd]

Since we're on the topic: we managed to port LLVM to the 65xx series of microprocessors, and LLVM has a fairly new flang compiler front-end built in nowadays. I imagine it would be an incremental amount of work to get the flang front-end working with our existing llvm-mos backend. https://www.llvm-mos.org

[BillG]

barrym95838 wrote:

Tor wrote:

... With tons of codes there will always be typos, which would go unnoticed with implicit types ...

A read a story several years ago about a guy who was reviewing a gigantic FORTRAN program in preparation for translating it or upgrading/extending it, and decided to write a script to do some automated analysis of the source. This was working code, but his script found a variable buried deep within it that was initialized but never used. The initialized value was 1.2 and the variable was named something like DO31670I ... doh!

That line of code must have been

Code: Select all

DO3167I=1.2

which the compiler sees literally but the programmer meant to type

Code: Select all

DO 3167 I = 1, 2

FORTRAN ignores spaces, even within identifiers!

That type of fragment is a classic example used in compiler textbooks of how the lexical analyzer for FORTRAN is special; it must look ahead to properly do its job. But I digress...

I have several toy compilers in various states of incompletion. If there is enough interest, I may consider creating one for FORTRAN.