Developing a new language - ACUSOL

[Pab]

LOL. It never occurred to me, I've started thinking of it as "Accomplish" as was suggested here, but I'll leave the final name up to the teeming hordes on here.

 

In other news, I have gone over to the dark side and used recursion. I had been trying to write my math parsing routines without recursion to make them easier to translate to the Atari, but after three days I just said to heck with it and threw it out the window and took the easy route and wrote a recursive parser.

 

It will be harder to translate when the time comes, but at least I have some quick and dirty code to use in this bootstrap compiler.

[flashjazzcat]

LOL. It never occurred to me, I've started thinking of it as "Accomplish" as was suggested here, but I'll leave the final name up to the teeming hordes on here.

I'm tempted to suggest "ComPILE" but I don't want to labour the point.

[snicklin]

I'm tempted to suggest "ComPILE" but I don't want to labour the point.

 

Nice one! How about "ComPOOte!"?

[Pab]

Yeah, very funny. I'm reminded of when Catherine Deneuve sued a magazine that called itself "Deneuve." Their initial reaction was to rename it "BHL," which Deneuve was fine with until she discovered that it meant "Butt-Headed Lesbian."

 

In other words, don't push your luck with the name.

[+Ripdubski]

Well, I expect rapid, soothing relief from this compiler when it's done.

It also shrinks your code.

Edited March 25, 2014 by Ripdubski

[Mathy]

Hello guys

 

"TurboAction!"

 

Sincerely

 

Mathy

Edited March 25, 2014 by Mathy

[flashjazzcat]

"Preparation 8"

[Alfred]

That's too bad you've gone and used recursive descent. That might preclude there being a native version of the compiler.

[+MrFish]

Hello guys

 

"TurboAction!"

 

Sincerely

 

Mathy

 

I like the idea of something with the "Action" in the name. How about "ReAction"?

[phaeron]

That's too bad you've gone and used recursive descent. That might preclude there being a native version of the compiler.

 

Not necessarily. I used a bytecode-based recursive descent parser with backtracking in Altirra BASIC, and IIRC the parser module was just over 1K.

[Pab]

 

I like the idea of something with the "Action" in the name. How about "ReAction"?

 

To have a reaction, it helps to have a catalyst. What about "Catalyst?"

[+MrFish]

 

To have a reaction, it helps to have a catalyst. What about "Catalyst?"

 

Well, I was thinking that "Action" was the catalyst. Action -> ReAction. Although Action is maybe more like the main ingredient in this case.

 

I was also thinking of it like Action replay or remix.

Edited March 26, 2014 by MrFish

[Pab]

Good morning. Thought you all might like a status update.

 

• 8 and 16 bit math done. I will add 32 bit math and LONGCARD/LONGINT after the initial version of the compiler is complete. It;s not necessarily needed for the bootstrap version of the compiler.
• Mathematical expression parsing is completed.
• Boolean expresions are working except for NOT, which is one of the first things to add to my code this morning.
• IF-THEN-FI working. ELSE to come later today.
• Inline machine code supported.

On the agenda for today:

• First code for the RTL, mainly PRINT and STR routines so I can finally have my test programs report results instead of looking at variable values in a monitor program.
• Support for the USES clause to include libraries, mainly so I don't have to copy and paste my PRINT and STR code.
• Adding NOT to boolean evaluation
• ELSE
• Loops, starting with FOR and moving on to REPEAT and WHILE.

Still to come:

• Full support for banking. (Lot of TODOs in my code right now.)
• POINTERs
• Support for object methods
• Rest of the RTL.

I'm also thinking of delaying FLOAT support until after the first version of the bootstrap compiler is done. Like 32-bit math, it can be added right before work begins on the native version.

[Pab]

Well, finally tracked down the bug I was chasing after for a couple of hours last night. It was in my code being compiled, not the compiler itself. Grr. Nothing worse than finding out the routine you've been over with a fine tooth comb all evening was right in the first place.

[flashjazzcat]

Nothing worse than finding out the routine you've been over with a fine tooth comb all evening was right in the first place.

 

Only pleasurable when inspection was prompted by a "bug report".

[Pab]

Some people don't understand why I refer to beta testers as "people poking at your program with a sharp stick."

 

By the way, I've just wasted the entire morning playing around with SpartaDOS X 4.46 under Altirra. You guys all did a wonderful job with it!

[Pab]

The beginnings of a RTL, mainly because I got sick of checking results in Altirra's debug mode monitor.

 

This file ("PRINT.ACC" on my machine) handles various PRINT procedures, and includes StrB and StrC functions.

PROC StrC(CARD c,STRING POINTER s)
[$A5$A0$85$CB$A5$A1$85$CC$A9$0A$85
 $CD$A9$00$85$CE$A9$00$85$AF$20
 !DIV $A6$AF$A5$D6$18$69$30$9D$80
 $04$E6$AF$A5$D4$85$CB$D0$EB$A5$D5
 $85$CC$D0$E5$A5$A2$85$D4$A5$A3$85
 $D5$A5$AF$AA$A0$00$91$D4$C8$BD$7F
 $04$91$D4$CA$D0$F7]
RETURN

PROC StrB(BYTE b,STRING POINTER s)
[$A5$A2$85$A3$A5$A1$85$A2$A9
 $00$85$A1$4C StrC]
RETURN

PROC PutD(BYTE ICB,a)
 [$A5$A0$0A$0A$0A$0[attachment=334744:smallbird.gif][attachment=334745:largebird.gif]A$AA$A9$A1$9D$44
  $03$A9$00$9D$45$03$A9$01$9D$48$03
  $A9$00$9D$49$03$A9$0B$9D$42$03$20
  $56$E4]
RETURN

PROC PrintD(BYTE ICB, STRING s)
 [$A6$A0$0A$0A$0A$0A$AA$A5$A1$85$D4
  $9D$44$03$FE$44$03$A5$A2$85$D5$9D
  $45$03$A9$0B$9D$42$03$A0$00$B1$D4
  $9D$48$03$20$56$E4]
RETURN

PROC PrintDE(BYTE ICB, STRING s)
 [$20 PrintD $A9$9B$85$A1$4C PutD]

PROC Print(STRING POINTER s)
 [$A5$A2$85$A3$A5$A1$85$A2$A5$A0$85
  $A1$A9$00$85$A0$4C PrintD]
RETURN

PROC PrintE(STRING POINTER s)
 [$20 Print $A9$00$85$A0$A9$9B$85
  $A1$4C PutD]
RETURN

PROC PrintC(CARD c)
STRING str=$580
  StrC(c,str)
  Print(str)
RETURN

PROC PrintB(BYTE b)
STRING str=$580
  StrB(b,str)
  Print(str)
RETURN

For those curious about the reference to !DIV in the StrC code, that's a macro telling the compiler to swap in the address of the 16-bit division routine as included in the math micro-runtime it writes at the beginning of any program. I also have macros for !ADD !SUB and !MULT with others coming for !BANK !UNBANK !BANKPEEK !BANKPOKE !BANKCPEEK and !BANKCPOKE. These will mainly be handy when writing the runtime but could also be used by any programmer who wants to use them in inline machine code.

 

First program using these was to test IF-THEN-ELSE-FI statements....

MODULE ORG=$1F00

USES PRINT

CARD b

PROC MAIN
   b = 4
   Print("b is currently ")
   PrintC(b)
   PrintE(".")
   IF b > 5 THEN PrintE("LARGE bird!") 
   ELSE PrintE("Small bird.")
   FI
   PrintE("We are done here.")
RETURN

[Mathy]

Hello guys

 

 

I like the idea of something with the "Action" in the name. How about "ReAction"?

 

How about "DeReAction!"? "De Re" as in "De Re Atari"

 

Sincerely

 

Mathy

[Pab]

Change to the way the language is parsed today. Originally I had RETURN and END aliased to each other. Now there is a difference. Ending a block with a RETURN will write an RTS (or RTI for an interrupt, more on that later) to the program code. An END will just end the block of code.

[Pab]

Been a busy day "in real life" today, but here's the day's progress report.

 

Added today:

• IF
• FI
• THEN
• ELSE
• ELSEIF
• DO
• OD
• WHILE
• UNTIL
• INTERRUPT

All but the last should be familiar to Action programmers. "INTERRUPT" starts a procedure to be used as an interrupt, which will close with an RTI instead of an RTS when the RETURN statement is encountered.

Edited March 29, 2014 by Pab

[Pab]

At a point where I could really use some help.

 

My original plan for loading program code into banked RAM was to essentially let DOS do the work. As you can see if you disassemble this executable (rename the program to .COM or .EXE since I can't upload anything with either of those extensions), the plan was to first stash the original value of PORTB at the beginning of the load (the first segment here), load the first module which would include the banking runtime, math routines, and other bits of important stuff before anything else (segment 3, at $1F00) and then we would be ready for anything.

 

When the time came to load a segment into a bank, a routine would again be written into $480 which would call the Bank Selection routine (here at $1F00) for the bank we wanted to load into. Then the next segment would presumably be loaded into the specified bank.

 

It appears to me that messing with PORTB during a binary load under almost any DOS has unintentional consequences, leading to a crash under every DOS I tried it with. Even DOS 2.0S.

 

Thoughts? Ideas? Alternatives? Pointing out what I'm doing wrong?

test16.bin

[flashjazzcat]

I wouldn't rely on manipulating PORTB during binary load. The first thing DOS (for example, SpartaDOS X) might do after running some segment init code is write to PORTB to bank in its own code library. Similarly, if you happen to load from a RAMdisk, DOS will likewise issue PORTB writes all over the place. To load code into extended RAM, best bet would be to let it load some place else and copy it into the banking window yourself (i.e. in the code's init segment).

Edited March 30, 2014 by flashjazzcat

[Pab]

Hm. I was afraid it was going to come down to that. I would have liked to find an alternative to load-and-move.

[Pab]

How does this sound for an option? Segments that need to be loaded into banked RAM will actually be loaded into memory starting at $8000 and moved after the segment is loaded. This would mean that any code destined to be compiled into the area from $8000-$BFFF would have to come in a later MODULE than the routines destined for the banks. Or, if you plan on having the main program in cartridge RAM at $A000-$BFFF (including the runtime), you just have to make sure you're not putting more than 8K in any MODULE. Sound like a reasonable restriction?

[Alfred]

It appears to me that messing with PORTB during a binary load under almost any DOS has unintentional consequences, leading to a crash under every DOS I tried it with. Even DOS 2.0S.

 

Thoughts? Ideas? Alternatives? Pointing out what I'm doing wrong?

test16.bin

 

You must be doing something wrong. DOS 2.0 wouldn't be even looking at $D301 during its operations, so there's no reason it would crash.