Developing a new language - ACUSOL

[Pab]

Not a proper IDE. Just edit and status windows, really. That's why I broke the "CompilerUnit" into its own unit; so both command line and GUI versions would be easy to develop.

 

Trust me, in debugging, it's a lot easier for me to work with a GUI than a command line. That's the main reason the GUI is there.

[Alfred]

The idea at this point is to build a bootstrap compiler, with which I (and hopefully some volunteers) can write a native compiler that will run on the Atari that anyone can use. I'm going to keep putting out alpha versions here for people to look at and play around with. One will be coming tomorrow if all goes well.

 

 

 

I'm a bit skeptical that a native compiler can be produced that will fit in the memory of a stock machine. I suspect it will end up being XE-only.

[Pab]

I am under no delusion that it would fit in a 48k machine. An XE would be a necessity.

[Pab]

Sigh. Broke something in IO.ACC right before the release. If you're going to use the current version, please change the Print routine in your IO.ACC to this:

PROC Print(STRING s)
//
// Print string to IOCB #0
//
 [$A5$A2$85$A3$A5$A1$85$A2$A5$A0$85
  $A1$AD device $85$A0$4C PrintD]
END

[Pab]

Sigh. The last build completely broke banked RAM support. Ended up initializing it before space had been actually allocated for the bank table. So things go boom.

 

Will have updated build out later this week that will fix that and add a couple more things.

[Pab]

Some major changes to the GUI for the new build coming tomorrow or Friday...

 

[Pab]

New build today: version 0.3.1.47.

 

Arrays within objects and pointers are still not quite ready to go. Wanted to tackle some more annoying bugs and other stuff that would prove easier to do before getting tied up completely in knots with those two.

 

 

Here's the Changelog:

 

GUI

===

* Major changes, moving compiler status window to its own resizeable window (like the object data window), adding multi-tabbed editor, and menu instead of buttons.

COMPILER:

=========

* Units are scanned to see if they've already been used. This allows units to use other units without the worry that we'll be redefining and recompiling everything.

* Fixed bug where "NOT x" was not recognized as an expression.

* Fixed major bug in BankPeek/BankPoke routines that would have selected wrong bank under certain circumstances.

* Added BankCardPoke and BankCardPeek routines to micro-runtime with corresponding labels !BANKCARDPOKE and !BANKCARDPEEK

* Banking code rewritten so that any reference to bank 0 will automatically default to the main bank. Workaround for ML code that jumps to bank selection without testing for 0 bank.

* Fixed bug where variable in banked RAM passed to a procedure would pull the information from bank 0 instead of the proper bank.

* Added support for passing pointer to variable (with @ operand) in procedure calls.

RTL:

====

* Fixed bug where Printing a blank string would print a heart instead.

* Fixed bug where OPEN was not resetting EOF flags.

* Fixed bug where trying to INPUT past EOF returned garbage string.

* Fixed bug where Close() and Get() still used direct CIO instead of error-checking.

* New unit MEMORY.ACC includes the following calls:

CARD FUNC Allocate(CARD len)
BYTE FUNC AllocateHigh(BYTE len)
PROC DeAllocate
PROC Zero(BYTE POINTER b CARD len)
PROC SetBlock(BYTE POINTER b CARD len BYTE v)
BYTE FUNC Peek(BYTE POINTER b)
CARD FUNC PeekC(CARD POINTER c)
PROC Poke(BYTE POINTER bp BYTE b)
PROC PokeC(CARD POINTER cp CARD c)

 

Accomplish Compiler 0.3.1.47 4-16-15.zip

[Xuel]

Nice work!

 

Any chance you could offer .XEX as the executable extension instead of .COM?

 

Also, I notice that pressing Tab in the GUI shifts focus between GUI elements instead of inserting a Tab. Is this intended?

[Kyle22]

Nice work!

 

Any chance you could offer .XEX as the executable extension instead of .COM?

 

Also, I notice that pressing Tab in the GUI shifts focus between GUI elements instead of inserting a Tab. Is this intended?

Just rename .COM to .XEX, they are both names for Binary files.

Edited April 16, 2015 by Kyle22

[Xuel]

Just rename .COM to .XEX, they are both names for Binary files.

 

Yep, I'm just lazy and wanted the .XEX as an option in the Save file as... dialogue's "Save file type" pulldown. That way you can also quickly save over an existing .XEX by just double clicking on it.

[Kyle22]

 

Yep, I'm just lazy and wanted the .XEX as an option in the Save file as... dialogue's "Save file type" pulldown. That way you can also quickly save over an existing .XEX by just double clicking on it.

You have a good point.

[Pab]

Nice work!

 

Any chance you could offer .XEX as the executable extension instead of .COM?

 

Also, I notice that pressing Tab in the GUI shifts focus between GUI elements instead of inserting a Tab. Is this intended?

 

1. Yes. Just added it for the next build. Will now allow you to choose .COM, .XEX, .EXE, and "Any file" as types.

 

Is there any appreciable difference between XEX and COM/EXE other than the choice of extension to distinguish an XE (8-bit) executable from other machines'?

 

2. Was not intended. Fixed. In the new tabbed code for the GUI I have to create the TMemo objects by hand for each page at runtime, and left out a "Memo.WantsTabs := True" in my Lazarus code.

 

One little undocumented thing: because I'm switching back and forth between Pascal code for Lazarus and Accomplish code to test the compiler constantly, I made the compiler treat ":=" as equivalent to "=" in assignment statements. Not intended as a feature of the language, but a crutch for me since I keep accidentally using := for assignment when writing the Atari code.

[Pab]

Oh, also, don't know if I mentioned this since it's impossible to do with the Windows editor, but the compiler treats CHR$(30) (the ATASCII left arrow) as a synonym for "<<"/"LSH" and CHR$(31) (the ATASCII right arrow) as a synonym for ">>"/"RSH."

 

Might see what I can do about the parser treating CHR$(155) as a CR/EOL so it can compile ATASCII files on the PC side without conversion.

[Pab]

Might see what I can do about the parser treating CHR$(155) as a CR/EOL so it can compile ATASCII files on the PC side without conversion.

 

Hmm. That modification was even easier than I thought. Added to the next build. I imagine it will mainly be easier with the coming command line version of the compiler than with the GUI

[Xuel]

Is there any appreciable difference between XEX and COM/EXE other than the choice of extension to distinguish an XE (8-bit) executable from other machines'?

 

XEX is just a new de facto standard filename extension for Atari executables. One benefit over COM/EXE is differentiation from Dos/Windows executables which is really handy for associating emulators with the file type.

[Pab]

Didn't really say much about three routines I added to the RTL which weren't around in Action!:

CARD FUNC Allocate(CARD Len)

This routine allocates "Len" bytes of memory beginning at MEMLO and adjusts MEMLO accordingly. Returns the address of the first byte of reserved memory. Handy if you need to dynamically allocate some space at runtime.

BYTE FUNC AllocateHigh(BYTE Len)

This allocates "Len" pages' worth of high memory below the current RAMTOP and adjusts RAMTOP accordingly. Returns the number of the first page reserved. Handy for making room for display lists, PM graphics, and other uses. After using, suggest changing graphics mode to move DL and display RAM back below the new RAM (unless you are using a custom DL and self-allocated display RAM).

PROC DeAllocate

This releases all RAM reserved by Allocate and AllocateHigh calls, putting MEMLO and RAMTOP back where they were before any calls were made.

 

It should go without saying that all RAM set aside via this technique is in the main bank, since really MEMLO should never be as high as $4000 and RAMTOP should never be as low as page $80 (at least not on anything other than an unmodified 400 or 600XL, in which case there's no extended memory to begin with).

[Pab]

 

XEX is just a new de facto standard filename extension for Atari executables. One benefit over COM/EXE is differentiation from Dos/Windows executables which is really handy for associating emulators with the file type.

 

What I thought.

[Pab]

Quick poll question for future builds:

 

Since the project is pretty well along now, and the compiler becomes more functional with each build I release, would you folks prefer that I bundle the source code separately? Say have one ZIP with the GUI compiler, the forthcoming command line compiler, and the RTL and a separate one with the Lazarus source code for those who want to play around with that?

[Alfred]

My vote is no. It's a pretty small file, no reason not to just bundle everything together.

[Pab]

Not sure it's enough of a milestone to release the build (unless you folks want it/need it badly enough), but at long last I have pointers working.

 

If there's no outcry for an immediate release I'll start work on a few other things looking toward a build in the middle of next week.

[Pab]

Hi, folks.

 

I'd hoped to have the new build out today, but I'm adding a few bells and whistles. Expect the build by some time tomorrow afternoon.

[Pab]

This week's build - version 0.4.0.18

 

Major additions:

 

• Command line compiler - Command line version of the compiler. Syntax ACCOMP -i source -o object [-l logfile] [-c codelog]
• LONG variables - signed 32-bit variables. Also includes 32-bit math calls for ML routines, LONG POINTERs and LONG ARRAYs.
• Addition of InputSD routine to read text line from a file. Other permutations forthcoming.
• Support for XEX and EXE extensions when saving file.

Full changelog follows:

 

Changes in version 0.4.0.18

GUI

===

* Fixed bug where Tab key would take focus away from the editor instead of inserting spaces.

* Added support for XEX and EXE extensions in dialog when saving object code.

* Fixed bug where right-click on editor window would open menu that should have been for the tabs.

COMPILER:

=========

* Included command line version of the compiler.

* Support for LONG variables - Signed 32-bit integer

* New labels for ML code pointing to 32-bit math package: !ADD32 !SUB32 !MULT32 !DIV32

* Abandoned support for floating point variables.

* Now treats ATASCII EOL as a carriage return in source files, allowing compiling of ATASCII files without conversion.

* Pointer support finalized.

* Added ability to define an array in code through [ ] codeblocks without specifying allocating 0 bytes as previous versions had required through an oversight of mine. Arrays defined this way are theoretically open ended.

RTL:

====

* Had left "DEFINE NOARGS" out of portions of MEMORY.ACC where it should have been. This led to a lot of bytes being needlessly allocated. Fixed.

* The following calls added to IO.ACC:

PROC StrL(LONG l STRING POINTER s)
PROC InputSD(BYTE d STRING st)
PROC PrintLD(BYTE d LONG l)
PROC PrintL(LONG l)
PROC PrintLDE(BYTE d LONG l)
PROC PrintLE(LONG l)

 

Accomplish compiler 0.4.0.18 4-21-15.zip

[Pab]

Quick question: Other than library functions (since the RTL is still very much a work in progress), is there any aspect of the Action language I haven't recreated in Accomplish? Considering that TYPE is replicated in object classes (in fact, TYPE is aliased to CLASS in the compiler) and the SET directive is meaningless on a cross-compiler, I think the pointers were the last big hurdle.

 

I'd like to start clean-up on some of the things I've saved toward the end (arrays in objects, error handling during compilation) and then move on to the biggest part of this stage: implementing two-pass compilation. But before I do all that I'd like to have the language itself pretty much locked down until after release.

[Pab]

Been concentrating on the RTL this week, so I'm going to post this one on its own.

 

This is GRAPHICS.ACC, the base graphics routines.

MODULE // Should always be in the main bank.

USES IO

BYTE Color

DEFINE NOARGS

PROC Graphics(BYTE mode)
[$A5$A0$48$A9$53$8D$80$04
 $A9$9B$8D$83$04$8D$81$04
 $A9$45$8D$82$04$A2$60$A9
 $0C$9D$42$03$8D$42$03$20 
 CIO $A2$00$20 CIO $A9$82
 $8D$44$03$A9$04$8D$45$03
 $A9$0C$8D$4A$03$A9$00$8D
 $4B$03$A9$03$8D$42$03$20 
 CIO $A2$60$A9$03$9D$42$03
 $A9$80$9D$44$03$A9$04$9D
 $45$03$68$A8$D0$01$60$29
 $30$49$10$09$0C$9D$4A$03
 $98$9D$4B$03$4C CIO]

PROC Position(CARD x BYTE y)
[$A5$A0$85$55$A5$A1$85$56
 $A5$A2$85$54$60]

PROC Plot(CARD x BYTE y)
[$20 Position $A9$06$85$A0
 $AD Color $85$A1$4C PutD]

PROC DrawTo(CARD x BYTE y)
[$20 Position $AD Color
 $8D$FB$02$A2$60$A9$11$9D
 $42$03$4C CIO]

PROC Fill(CARD x BYTE y)
[$20 Position $AD Color
 $8D$FD$02$A2$60$A9$12$9D
 $42$03$4C CIO]

PROC SetColor(BYTE Col,Hue,Lum)
[$A4$A0$A5$A1$0A$0A$0A$0A$99$C4$02
 $A5$A2$18$79$C4$02$99$C4$02$60]

BYTE FUNC Locate(CARD x BYTE y)
[$A5$A3$85$55$A5$A4$85$56
 $A5$A5$85$54$A9$06$85$A3
 $4C GetD]

UNDEFINE NOARGS

[greblus]

Pab It looks really promissing and I keep my fingers crossed for your efforts.

 

Cheers,

W.