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.

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?

What I thought.

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

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

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.

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.

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

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

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.

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

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

Heck, once I got it properly configured I made the switch full-time to Altirra for emulation. Its debugging capabilities are unparalleled. I could never have gotten as far as I have in developing Accomplish without the ability to single-step through memory while a program was running.

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.

For your inspection and amusement, the latest build. I'm working on pointers at the moment, but they're giving me a headache so I thought I'd put out what I had. WHAT DOESN'T WORK (yet): * Pointers, for the most part. * Arrays within classes. Working on this, too. Need to test some stuff. * Error vector for custom error handling. Being rewritten to not require page zero location. * FLOATs. Still debating the need for them. * STRING FUNCs * Probably dozens of new bugs I added in but haven't detected yet. Sigh. Changelog for this version: GUI: ==== * Added ability to load/save source files. * Layout changes. COMPILER: ========= * Added object support. * Added ACTIONARGS flag to pass arguments in registers. * Fixed bug in assigning address of fixed location procedure. * Fixed bug in parsing multiple arguments in procedure calls. * Finalized support for INTeger variables (signed 16-bit) * Added !BANKPEEK, !BANKPOKE, and !BANKCOPY labels for ML code. * Fixed bug where function calls in assignments would skip over arguments. * Bug: Bank initialization code was never run unless code was placed in a bank. For the time being, the bank initialization routine is ALWAYS the first segment of a file, at least until we have two pass compilation and will know whether or not we need banked support. * Fixed bug in storing the address of a variable or procedure in another variable. (a = @b). If assigning to a CARD, the result will be the address (no bank information) of the variable. If assigning to a pointer, banking information will be included. RTL: ==== * Deprecated PRINT.ACC * New unit IO.ACC includes the following calls: PROC StrC(CARD c,STRING POINTER s) PROC StrB(BYTE b,STRING POINTER s) PROC StrI(INT i,STRING POINTER s) PROC XIO(BYTE d,scrap,c,m,a STRING f) PROC Open(BYTE d STRING f BYTE m,a) PROC Close(BYTE d) BYTE FUNC GetD(BYTE d) BYTE FUNC Get(BYTE d) PROC PutD(BYTE ICB,a) PROC PrintD(BYTE ICB, STRING s) PROC PrintDE(BYTE ICB, STRING s) PROC Print(STRING s) PROC PrintE(STRING POINTER s) PROC Put(BYTE b) PROC PrintC(CARD c) PROC PrintCE(CARD c) PROC PrintID(BYTE d INT i) PROC PrintI(INT i) PROC PrintIDE(BYTE d INT i) PROC PrintBD(BYTE d,b) PROC PrintB(BYTE b) PROC PrintBE(BYTE b) PROC PrintBDE(BYTE d,b) CLASS TIOCB BOOL ARRAY EOF[8] BYTE device BYTE LastError TIOCB ARRAY IOCB[8] = $340 AccomplishCompiler 0-2-0-14.zip

One thing I wanted to get fully functional before I put out the latest build, just because it was the first feature request I remember seeing that I knew I could get functional in a hurry: support for interrupts. It's now possible to write a procedure to be used as an interrupt simply by replacing the PROC keyword with INTERRUPT. Doing this will add code to push the registers onto the stack, and when a RETURN is reached, the registers will be popped off of the stack and an RTI used to return instead of RTS. Example program, quick and dirty DLI. MODULE ORG=$1F00 CARD DLIVector=$200 CARD DLAddress=$230 BYTE InterruptEnable=$D40E BYTE CH=$2FC BYTE ARRAY DisplayList[0] [$70 $70 $70 $42 $40 $9C $02 $02 $02 $02 $02 $02 $02 $02 $82 $02 $02 $02 $02 $02 $02 $02 $02 $02 $02 $02 $02 $02 $02 $41 DisplayList] INTERRUPT ColorShift BYTE COLPF2=$D018 COLPF2=$38 RETURN PROC MAIN CARD OldDisplayList // Stash the old DL address OldDisplayList = DLAddress // Set our interrupt vector DLIVector = @ColorShift // Zap in our new display list DLAddress = @DisplayList // Enable Interrupt InterruptEnable = 192 // Wait for a key CH = $FF WHILE CH=$FF DO OD // Go back to normal. InterruptEnable = 64 DLAddress = OldDisplayList CH = $FF RETURN

As for the public beta, I'm not sure there will really be such a thing. 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. As for the manual, I'll put together a language reference and tutorial, and docs for the RTL, but a full manual will probably have to wait until we're well into the native compiler.

Here's an interesting question. About to write the RTL code for the XIO command, I was reminded of the weird syntax Action! used for its XIO routine: XIO(device,0,command,aux1,aux2,filespec) What was with the extra byte (which apparently was unnecessary because they said to just use a 0 there) between the device number and command? And other than backwards compatibility with Action! is there any reason to keep it? The one thing I can think of is that since Action! passed the first three bytes in the registers, this kept the X register free and put the command in the Y register. This way the routine could just ASL A four times, TAX, and STY ICCOM and not have to do anything with X. But if so, it's a kludgy way of doing things.

Yeah, it was just a crazy idea. Scanning for open IOCB's was my first thought and the way I was probably going to go about it, but I was just curious. Once the RTL for Accomplish is well underway, I might write some libraries to use the SDX kernel natively just because I can, but until then....

Here are the 32-bit multiply and divide routines I was looking at: http://www.6502.org/source/integers/32muldiv.htm

You guys are right. There's really no benefit to using zero page for those locations since indirect jump (which is used with the error vector) needs a two byte argument anyhow, and since LastError and Device will be called so infrequently that the byte saved in each reference just isn't worth tying up those locations. Will do a little rewriting to move those values into ones allocated dynamically when using the I/O runtime. That leaves the only locations needed by the language as $A0-$AF and $C9-$D0. I only use the FP locations for scratch memory, such as values returned from the micro-runtime routines, so nothing will be lost if we choose to fully implement floats. I'm thinking about the possibilities of implementing 32-bit LONG variables, which might require more locations. Right now the micro-runtime routines use CB/CC and CD/CE for the operands, with CF and D0 being used generally for bank numbers when referring to locations in banked RAM. If I need to add 32 bit math, one operand would have to be from $CB-CE. I guess the second operand could be $CF-$D2, since bank numbers would never be needed in 32 bit operations. That way the result could be passed in $D4-$D7. I think in the long run we'd be better off implementing 32-bits than floats. Not that one rules out the other. Just implementing floats is turning out to be a big pain in the ass and the time I would invest in it would be better spent on LONGs.

Since I wanted to start doing some more elaborate programming (and figured some of you out there would too) to test this thing as I develop, I've spent the last couple of days working on I/O routines for the runtime package. I'll share them when I upload the latest build. Also put into place (sort of needed it if disk I/O is in the offing) some basic error handling in the runtime. New additions to the language's page 0 memory map include: $C5 - DEVICE - Default device # $C6 - LASTERROR - Error returned by CIO or other routines $C7/$C8 - ERRORVEC - Pointer to a routine to use in place of built-in error handling Also, like Action!, an EOF is NOT treated as an error, but just sets a flag. The end-of-file status can be checked in the boolean array EOF[x]

Working on Accomplish, toying around while writing runtime routines for I/O. I had a really weird thought. Is it possible to overcome the limit of seven IOCB's by basically creating a "virtual IOCB" for a file? Imagine this scenario: * Stash the values in locations $3B0-$3BF (IOCB #7) * Load in our own set of values from a 16 byte "virtual IOCB" * Operate on those values through IOCB #7. Open, read, write, etc. * Swap out the new values with the original values when done I'm thinking it might be neat to have an Accomplish class for file access that doesn't require the programmer to plan out exactly which IOCB's are used for which files at what time, and leave it to the system to handle it.

I have one or two more things I want to tackle before I post another build. Probably in the next day or two.

Another example, which I mainly used to test class arrays. A very unnecessarily roundabout "Hello World" program. MODULE ORG=$1F00 CLASS TIOCB BYTE ID BYTE Number BYTE Command BYTE Status CARD Address CARD PutOne CARD Length BYTE ARRAY Aux[6] PROC Run(BYTE a,x) END // Array pointing to IOCB's // in RAM TIOCB ARRAY IOCB[8] = $340 // String in fixed spot since // I don't have pointers fully // functional yet. STRING s[128] = $0580 // Pass args in registers DEFINE ACTIONARGS PROC CIOV = $E456(BYTE a,x) UNDEFINE ACTIONARGS // End code using ActionArgs PROC TIOCB.Run(BYTE a,x) CIOV(a,x) RETURN PROC MAIN s = "Hello World" IOCB[0].Command = 11 IOCB[0].Address = $581 IOCB[0].Length = 11 IOCB[0].Run(0,0) IOCB[0].Length = 0 IOCB[0].Run(155,0) RETURN