Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #29686 > unrolled thread

DurexForth v1.3 - MML support

Back to article view | Back to comp.lang.forth

Contents

  DurexForth v1.3 - MML support Whammo <sidciavic@gmail.com> - 2014-04-16 17:20 -0700
    Re: DurexForth v1.3 - MML support "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-16 22:50 -0400
      Re: DurexForth v1.3 - MML support Whammo <sidciavic@gmail.com> - 2014-04-17 01:09 -0700
      Re: DurexForth v1.3 - MML support Mark Wills <markwills1970@gmail.com> - 2014-04-17 03:14 -0700
        Re: DurexForth v1.3 - MML support "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-17 08:42 -0400
          Re: DurexForth v1.3 - MML support Mark Wills <markwills1970@gmail.com> - 2014-04-17 06:12 -0700
            Re: DurexForth v1.3 - MML support Hans Bezemer <the.beez.speaks@gmail.com> - 2014-04-17 23:31 +0200
              Re: DurexForth v1.3 - MML support Syd Rumpo <usenet@nononono.co.uk> - 2014-04-19 23:47 +0100
                Re: DurexForth v1.3 - MML support Hans Bezemer <the.beez.speaks@gmail.com> - 2014-04-21 17:47 +0200
    Re: DurexForth v1.3 - MML support hughaguilar96@yahoo.com - 2014-04-19 22:12 -0700
    Re: DurexForth v1.3 - MML support Whammo <sidciavic@gmail.com> - 2014-04-21 12:03 -0700
      Re: DurexForth v1.3 - MML support hughaguilar96@yahoo.com - 2014-04-21 19:58 -0700
        Re: DurexForth v1.3 - MML support Whammo <sidciavic@gmail.com> - 2014-04-22 00:37 -0700
          Re: DurexForth v1.3 - MML support hughaguilar96@yahoo.com - 2014-04-22 21:49 -0700
            Re: DurexForth v1.3 - MML support Whammo <sidciavic@gmail.com> - 2014-04-23 00:17 -0700
            Re: DurexForth v1.3 - MML support Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-04-23 03:06 -0700
              Re: DurexForth v1.3 - MML support hughaguilar96@yahoo.com - 2014-04-23 20:52 -0700
        Re: DurexForth v1.3 - MML support "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-22 04:29 -0400

#29686 — DurexForth v1.3 - MML support

2014-04-16: v1.3

 * Music Macro Language (MML) support!
 * Renamed some assembly mnemonics.
 asla, lsra, rora, rola, =>
 asl,a lsr,a ror,a rol,a
 * Allow strings longer than 256 bytes.
 * Optimized jsr. (Thanks to Kevin Lee Reno!)


http://code.google.com/p/durexforth/

[toc] | [next] | [standalone]

#29688

On Wed, 16 Apr 2014 20:20:16 -0400, Whammo <sidciavic@gmail.com> wrote:
>
>  * Music Macro Language (MML) support!
>  * Renamed some assembly mnemonics.
>  asla, lsra, rora, rola, =>
>  asl,a lsr,a ror,a rol,a
>  * Allow strings longer than 256 bytes.
>  * Optimized jsr. (Thanks to Kevin Lee Reno!)
>

No offense, but have you considered changing the name?

I would suggest considering removing "Durex".  If you
don't understand why, go to Google, enter Durex, click
on images, scroll through and look at the images until
you get it.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#29689

On Wednesday, April 16, 2014 7:50:43 PM UTC-7, Rod Pemberton wrote:
> On Wed, 16 Apr 2014 20:20:16 -0400, Whammo  wrote:
> 
> >
> 
> >  * Music Macro Language (MML) support!
> 
> >  * Renamed some assembly mnemonics.
> 
> >  asla, lsra, rora, rola, =>
> 
> >  asl,a lsr,a ror,a rol,a
> 
> >  * Allow strings longer than 256 bytes.
> 
> >  * Optimized jsr. (Thanks to Kevin Lee Reno!)
> 
> >
> 
> 
> 
> No offense, but have you considered changing the name?
> 
> 
> 
> I would suggest considering removing "Durex".  If you
> 
> don't understand why, go to Google, enter Durex, click
> 
> on images, scroll through and look at the images until
> 
> you get it.
> 
> 
> 
> 
> 
> Rod Pemberton

  It's:
A. Ironic
B. You that fails to 'get' it.

[toc] | [prev] | [next] | [standalone]

#29690

On Thursday, 17 April 2014 03:50:43 UTC+1, Rod Pemberton  wrote:
> No offense, but have you considered changing the name?

Perhaps it's designed for maximum-safety, mission-critical must-not-fail operation even after extensive use in the harshest of environments ;-)

[toc] | [prev] | [next] | [standalone]

#29691

On Thu, 17 Apr 2014 06:14:29 -0400, Mark Wills <markwills1970@gmail.com>  
wrote:
> On Thursday, 17 April 2014 03:50:43 UTC+1, Rod Pemberton  wrote:

>> No offense, but have you considered changing the name?
>
> Perhaps it's designed for maximum-safety, mission-critical must-not-fail
> operation even after extensive use in the harshest of environments ;-)

It could mean that it's not available when you need it.
It could mean that it's too little an environment for some, and vice-versa.
It could mean that it's a pain to use.
It could mean that it has a tough but flexible exterior.
It could mean that it's unable to detect the outside world.
It could mean that it's protected from most virus attacks.
It could mean that it's access to foreign function interfaces is limited.
It could mean that it's unable to achieve optimal results.
It could mean that it intereferes with half of it's users desires.
It could mean that it attempts to prevent the inevitable.
It could mean that it experiences random, but otherwise safe crashes.
It could mean that it fully catches at least one common mistake.
It could mean that it's bound for the trash after just one use.

etc.  ;-)


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#29692

On Thursday, 17 April 2014 13:42:02 UTC+1, Rod Pemberton  wrote:

> It could mean that it's protected from most virus attacks.

Ha ha!! Guys (softies) in the office laughing their heads off at this one!

:-)

[toc] | [prev] | [next] | [standalone]

#29695

Mark Wills wrote:

> On Thursday, 17 April 2014 13:42:02 UTC+1, Rod Pemberton  wrote:
>> It could mean that it's protected from most virus attacks.
It could also mean it lacks feeling and you'd rather do without!

<grin>

Hans Bezemer

[toc] | [prev] | [next] | [standalone]

#29724

On 17/04/2014 22:31, Hans Bezemer wrote:
> Mark Wills wrote:
>
>> On Thursday, 17 April 2014 13:42:02 UTC+1, Rod Pemberton  wrote:
>>> It could mean that it's protected from most virus attacks.
> It could also mean it lacks feeling and you'd rather do without!

What, with those dual stacks, and all that pushing and popping?

Cheers
-- 
Syd

[toc] | [prev] | [next] | [standalone]

#29748

Syd Rumpo wrote:
> What, with those dual stacks, and all that pushing and popping?
In German, "poppen" is unambiguous ;-)

Hans Bezemer

[toc] | [prev] | [next] | [standalone]

#29728

On Wednesday, April 16, 2014 5:20:16 PM UTC-7, Whammo wrote:
> 2014-04-16: v1.3
> 
>  * Music Macro Language (MML) support!
>  * Renamed some assembly mnemonics.
>  asla, lsra, rora, rola, =>
>  asl,a lsr,a ror,a rol,a
>  * Allow strings longer than 256 bytes.
>  * Optimized jsr. (Thanks to Kevin Lee Reno!)

What does "optimized jsr" mean?

According to your page, DurexForth is direct-threaded "for simplicity." Can you show us how your NEXT works? 

Normally in direct-threaded code, there is a JSR DOCOLON at the beginning of each colon word. DOCOLON will pop the return-address off the return-stack, and load this into the IP as that is where the threaded code begins. On the 6502 however, there is a quirk (a documented bug) in that the JSR pushes the return-address minus 1 rather than the return-address, so you have to add 1 to it before putting it in the IP. Is this what you do? 

I wrote a 65c02 Forth cross-compiler and I used subroutine-threading "for simplicity" --- this was derived from ISYS Forth for the Apple-IIc. I had a C64 too, but I programmed in SuperForth and never wrote my own Forth for the C64 --- I don't remember now if SuperForth was DTC or ITC, although I'm pretty sure that it wasn't STC.

The clever thing about ISYS Forth was that it used a split parameter stack. There were two stacks: one for the high bytes of the cells and one for the low bytes. Both stack were indexed by X. So, a single INX effected a DROP. Pushing a literal onto the stack looked something like this:

    LDA #lo
    LDY #hi
    STA $00,X
    STY $40,X
    DEX

Notice that the DEX is at the end, rather than the beginning. The bottom value on the stack is at $01,X (for the low half) and $41,X (for the high half). All code snippets that push a value end in DEX, and all code snippets that pop a value start with INX. This means that you often have a DEX followed by an INX --- the code optimizer gets rid of the DEX/INX pair as it does nothing. This was a really effective code optimization! Another code optimization was "jump-termination" (converting a JSR xxx RTS into a JMP xxx). These were the only two code optimizations done, but they made the code significantly faster and slightly smaller (also, jump-termination helps to prevent return-stack overflow). 

All in all, I think that ISYS Forth (and my cross-compiled Forth that was compatible with ISYS) was by far the fastest Forth available for the 65c02. It did use the 65c02 instructions, but they weren't crucial, so it could easily be ported over to the 6502 or 6510. I would recommend that you go with this and forget about threaded code for the 6502.

I wrote a program using my 65c02 cross-compiler that could symbolically find the derivative of mathematical equations. It would also simplify the equations by getting rid of superfluous stuff (such as adding a constant and then subtracting the same constant) that got introduced when generating the derivative. I had a long list of patterns that I could find and simplify.

[toc] | [prev] | [next] | [standalone]

#29755

"What does "optimized jsr" mean? 

According to your page, DurexForth is direct-threaded "for simplicity." Can you show us how your NEXT works? 

Normally in direct-threaded code, there is a JSR DOCOLON at the beginning of each colon word. DOCOLON will pop the return-address off the return-stack, and load this into the IP as that is where the threaded code begins. On the 6502 however, there is a quirk (a documented bug) in that the JSR pushes the return-address minus 1 rather than the return-address, so you have to add 1 to it before putting it in the IP. Is this what you do? "

 The optimized jsr was achieved by reusing the BASIC Sys code in the 
kernal thus allowing the loading and reading of the status register along with a, x, and y. That is, jsr as a forth word, rather than jsr-wrap as formerly.

 Next is an assembler macro, a direct jmp to the next routine which ends up being an indirect jmp through the instruction pointer stored in TMP by docol.

Docol behaves pretty much as you described and falls through to the next routine.
 I think dual parameter stacks is quite a good idea. Even if it only saves an inx it will save that many times over.

[toc] | [prev] | [next] | [standalone]

#29761

On Monday, April 21, 2014 12:03:16 PM UTC-7, Whammo wrote:
>  I think dual parameter stacks is quite a good idea. Even if it only saves an inx it will save that many times over.

It is an obvious idea, except that nobody ever thought of it other than the guy who wrote ISYS Forth --- it is obvious only in retrospect. :-)

DTC (2 bytes per call) does save memory compared to STC (3 bytes), but it is at least an order of magnitude slower. STC isn't so bad for memory as you might suppose. DROP is 1 byte. Also, jump-termination is 3 bytes, whereas in DTC it is not possible, so you have the final word and the EXIT at 2 bytes each for 4 bytes total. I'd recommend going with STC!

I forgot to mention one other optimization that I did. I told you that when inlining words I could often remove the DEX/INX pair if the first word ended in DEX and the second word began with INX. Also, I could do something similar even if I didn't inline the second word. When I inlined the first word I would remove the final DEX. Then, I would compile the JSR to 1+ the cfa of the second word to hop over the INX at the front. All of this optimization was easy to implement --- it was just peephole-optimization --- but it worked wonderfully for both boosting the speed and reducing the code size. 

I have a couple of C64s, but I don't have a disk drive anymore. Are very many people still interested in the C64? I was surprised that Mark Wills could find some 100 customers for his TI99/4A Forth cartridge --- apparently those 1980s computers still live on as hobby projects. Do you have the ability to make C64 cartridges? 

[toc] | [prev] | [next] | [standalone]

#29764

> It is an obvious idea, except that nobody ever thought of it other than the guy who wrote ISYS Forth --- it is obvious only in retrospect. :-)
> 
> 
> 
> DTC (2 bytes per call) does save memory compared to STC (3 bytes), but it is at least an order of magnitude slower. STC isn't so bad for memory as you might suppose. DROP is 1 byte. Also, jump-termination is 3 bytes, whereas in DTC it is not possible, so you have the final word and the EXIT at 2 bytes each for 4 bytes total. I'd recommend going with STC!
> 
> 
> 
> I forgot to mention one other optimization that I did. I told you that when inlining words I could often remove the DEX/INX pair if the first word ended in DEX and the second word began with INX. Also, I could do something similar even if I didn't inline the second word. When I inlined the first word I would remove the final DEX. Then, I would compile the JSR to 1+ the cfa of the second word to hop over the INX at the front. All of this optimization was easy to implement --- it was just peephole-optimization --- but it worked wonderfully for both boosting the speed and reducing the code size. 
> 
> 
> 
> I have a couple of C64s, but I don't have a disk drive anymore. Are very many people still interested in the C64? I was surprised that Mark Wills could find some 100 customers for his TI99/4A Forth cartridge --- apparently those 1980s computers still live on as hobby projects. Do you have the ability to make C64 cartridges?

 I'm just a very minor contributor to the project. Not familiar with any other forths. A big fan of Chuck Moore, and the C64.
 It would be an overhaul to implement the dual stack idea, maybe someday I'll roll my own c64 forth a la A Problem Oriented Language.
 One of the stated goals of Durexforth is for it to be self-contained. If I have a need for speed I can do assembly. So at least for me, compact code and understand-ability are prime. Still, 64k is a lot of memory!
 It is likely the C64 continues to be the most popular machine of the era.
I have a small collection of Commodore oriented hardware and once had the stuff to make my own carts. Sadly, I've sold off my best stuff on Ebay for a not so sad profit.
 There are several flash based drive solutions available for the 64. I use VICE 64 emulator for the most part nowadays. It's very good and probably cheating- so I'm lazy but still want to do cool things for my own pleasure. 
 
 

[toc] | [prev] | [next] | [standalone]

#29787

On Tuesday, April 22, 2014 12:37:44 AM UTC-7, Whammo wrote:
> > I forgot to mention one other optimization that I did. I told you that when inlining words I could often remove the DEX/INX pair if the first word ended in DEX and the second word began with INX. Also, I could do something similar even if I didn't inline the second word. When I inlined the first word I would remove the final DEX. Then, I would compile the JSR to 1+ the cfa of the second word to hop over the INX at the front. All of this optimization was easy to implement --- it was just peephole-optimization --- but it worked wonderfully for both boosting the speed and reducing the code size. 

I forgot another optimization that I did. Every word that popped a number off the stack started like this:

inx
lda $00,x
ldy $40,x
...

LIT normally was inlined like this:

lda # $ll
ldy # $hh
sta $00,x
sty $40,x
dex

When I compiled LIT and followed it by a word that started as described above, then I compiled LIT like this:

lda # $ll
ldy # $hh

Then I did a JSR into the following word to just past the prologue described above. Notice that the LIT is 4 bytes, which is the same as in a threaded system --- but way faster.

Okay, that is all of the optimizations that I did --- it has been many years, so I didn't remember everything right away. 

ISYS Forth is where I learned the concept of "producers" (words that push data onto the stack, such as LIT) and "consumers" (words that pop data from the stack, such as +), and how these are typically paired up in the user's source-code. This was the basis for most optimization in ISYS Forth, and is also the basis for most optimization in my Forth that I'm currently writing.

>  One of the stated goals of Durexforth is for it to be self-contained. If I have a need for speed I can do assembly. So at least for me, compact code and understand-ability are prime. Still, 64k is a lot of memory!

I don't know what you mean by "self-contained." Do you mean that it doesn't make use of any external code? The only external code that it could make use of is the BASIC interpreter, as that is the only code that is built in to the computer. I've seen this done, especially in regard to the floating-point stuff in BASIC. I didn't do it though --- ISYS had its own floating-point code (16-bit mantissa and 16-bit exponent). My program did symbolic math anyway, so numerical stuff wasn't a big part of it --- I did evaluate equations for the purpose of graphing them, but I didn't need much precision for that.

In the old days, people programmed in assembly-language and there was a lot of opportunity for clever programming. A good example is ISYS Forth with its dual stacks, while every other Forth for the 6502 had the high and low bytes adjacent. Now we have Anton Ertl and Bernd Payson writing Gforth in C, which I have zero interest in. The only people who would be interested are those who are too dumb to learn assembly-language, but still want to be low-level programmers for reasons unknown. Gforth is a toy because it is too slow to be used for commercial programs. But if people want a toy Forth to have fun with, I would really recommend that they use a 6502 Forth such as your DurexForth for the C64, rather than Gforth for Linux --- it has no practical value either way, but at least with the C64 it is fun.

[toc] | [prev] | [next] | [standalone]

#29791

, but at least with the C64 it is fun.   True!

 Self-contained may not be the best choice of verbiage.
I simply mean the editor, compiler and assembler all run on the machine in the forth environment.
 There is some support for the basic FP routines included. I haven't experimented much with them though I like the idea of leveraging the rom code.
 

[toc] | [prev] | [next] | [standalone]

#29793

@Hugh:

I like the concept of ISYS Forth. Is there any link for downloading it?

[toc] | [prev] | [next] | [standalone]

#29803

On Wednesday, April 23, 2014 3:06:28 AM UTC-7, Stefan Mauerhofer wrote:
> @Hugh:
> 
> I like the concept of ISYS Forth. Is there any link for downloading it?

I tried googling it, but turned up nothing. I think it is long gone. It was for the Apple-IIc, not the C64 --- I have a manual and a disk, but they are in storage in Colorado. I can't recall the name of the guy who wrote it.

[toc] | [prev] | [next] | [standalone]

#29765

On Mon, 21 Apr 2014 22:58:26 -0400, <hughaguilar96@yahoo.com> wrote:

> I have a couple of C64s, but I don't have a disk drive anymore.

I have bunch computers, drives, keyboards.  They're boxed up and
well packed away.  I'm not going to dig them out.

Most of the 1541 drives (5 1/4" floppy) had the heat expansion
issue.  This was where the low-quality metal frame of the floppy
expanded or warped after the drive warmed up causing infinite
frustration due to disk mis-alignment.

> Do you have the ability to make C64 cartridges?

A game cartridges was a small card inside a plastic case with a
small ROM/PROM/EPROM etc.


Did you know that Google is your friend?

"How to make your own C64 cartridge"
http://www.n2dvm.com/leif.html

"Project C64 Cartridge"
http://home.tiscali.nl/commodore/indexuk.html

"C64 cartridge shells"
http://www.vesalia.de/e_c64cartshell.htm

Transactor article on C64 cartridges w/schematic
http://ar.c64.org/rrwiki/images/5/57/The_Transactor_Vol07_04_1987_Jan_A_C64_Cartridge_without_Eproms.pdf


There are likely to be many more of those if you simply looked...

> Are very many people still interested in the C64?

The C64 was the most popular computer of it's era.

So, you tell us:

http://www.c64-wiki.com
http://www.commodore.ca/commodore-manuals/
http://cbmbasic.sourceforge.net/
http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/
http://vice-emu.sourceforge.net/
http://www.d64editor.com/
http://c64preservation.com/
http://www.chrismcovell.com/c64dtv.html
http://www.ide64.org/
http://rdist.root.org/2009/01/21/introducing-xum1541-the-fast-c64-floppy-usb-adapter/
http://www.ohgizmo.com/2007/02/22/commodore-64-disk-drive-adapter-for-pcs/
http://www.retrocomputers.eu/2011/05/05/sd2sio-commodore-to-sd-card-adapter/
http://www.6502.org/
http://www.c64.com/
http://www.c64forever.com/
http://www.richardlagendijk.nl/
...


Rod Pemberton

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web