Hugh Aguilar wrote:
BTW: My peephole-optimizer gets rid of that $FFFF BIT# most of the time --- it keeps track of whether the the ZF flag is valid for the A register (it usually is, because PLA LDA etc. all set ZF) --- if the ZF flag is already valid, the $FFFF BIT# is discarded as being redundant.
We aren't discussing peephole-optimization right now though.
Also, $FFFF BIT# can be replaced with TAY --- this is both faster and smaller.
This always works because I never carry data in Y through a branch --- the sections of code between branches are compiled and peephole-optimized as chunks --- doing peephole-optimization that covers entire control-structures would require a multi-pass compiler, and I only have single-pass at this time.
This thread seems to have devolved into me responding to myself --- apparently there is no interest in vino-816 --- I should not bother with further posts.
I mostly started this thread because of the previous exchange in the game-machine thread:
Hugh Aguilar wrote:
BigDumbDinosaur wrote:
As a well-written Forth kernel tends to be quite efficient (efficiency being one of the hallmarks of Forth), I'd expect that a kernel optimized for the 65C816 running in native mode would see a substantial performance gain.
It is obvious that William Mensch wanted to support C programming, so he added the offset,S and (offset,S),Y addressing-modes, but he was failing to support Forth.
If he doesn't want to support Forth, then I don't want to support his 65c816.
The 65c816 ISA was designed to support C, so supporting Forth is going to require contorted programming. I would do that if I was getting paid --- I'll do most anything for money, so long as it is not immoral or illegal, and I'm totally okay with implementing bad ideas --- do you want to hire me to write a Forth for the 65c816?
You've already said on this forum that you will never be convinced that Forth has any value, so I'm expecting that you are not going to hire me --- you don't actually believe what you said: "a well-written Forth kernel tends to be quite efficient (efficiency being one of the hallmarks of Forth)"
sark02 wrote:
Hugh Aguilar wrote:
do you want to hire me to write a Forth for the 65c816?
The question wasn't to me, but FYI if I wanted a Forth on any system, I'd want to hire a language expert.
What a slap in the face! SARK02 apparently believes that because I said that the 65c816 does not support Forth very well, this implies that I am incompetent at Forth.
He believes that it is an easy matter to find a "language expert" who knows more about Forth than I do and will say:
Quote:
The 65c816 is perfect for Forth! You are a genius to have chosen the 65c816 for Forth! You can pay by check, but your check has to clear before I begin work, Mr. Genius. I guarantee a kernel optimized for the 65c816 and a substantial performance gain! Woo hoo!
So, I began to wonder how a mighty "language expert" would design a Forth for the 65c816. Thinking about this, I came up with the vino816 design. Now SARK02 has to find a "language expert" who can think up a better design --- good luck with that!
I have no intention of actually implementing vino816 (not for free anyway; as I said above, I'm totally okay with getting paid to implement bad ideas). The only person I know of who uses the 65c816 for commercial projects is Garth Wilson, so I showed it to him first, but he was very unimpressed (he said it was "unnecessarily inefficient" and my code quality was so bad it made him "cringe"). AFAIK, Garth by himself is the entire 65c816 market on Earth, so if he is not interested, then nobody is.
BTW: William Mensch may have been thinking about Pascal rather than C. If so, then he was thinking about a crippled Pascal that lacks nested functions --- there is no register available for a local-frame pointer --- there were several such crippled Pascals in the 1980s, most notably Borland Turbo Pascal for the Z80 and later the 8088 (the bytecode Pascal for the Apple-II was also crippled afaik, although I never used it).