BASIC compiler update

[basicchip]

Version 8.16c of the compiler is attached here

Per user request, the ADDRESSOF operator accepts CONST arrays.

In order to support that, CONST arrays now allow multiple lines so

Code: Select all

const multi = {0,&H11,&H22,&H33
  ,&H44,&H55,&H66,
  &H77,&H88,&H99 
  }

if *(addressof multi +(9<<2)) = multi(9) then print OKmsg else print FAILmsg

is now allowed

But the old style of repeating CONST lines to build up larger arrays will no longer work. The reason for this is the original method built the constants in reverse order assigned in the constant/string space. Now they are build in normal (ascending in memory) order. A warning has been added to flag possible old style declarations.

Other things that were fixed

I/O(3) was allowed by the compiler in error, as it was not checking all the new compound operator errors
x and not(1<<3) is allowed again, this was changed when floating point was added.

To try this out, download the file and replace the version in the /Program Files (x86)/Coridium directory

[basicchip]

This version adds CONST BYTE ARRAYs to the BASIC compiler

The syntax is--

CONST CHARS AS BYTE = {1,2,3,4,5,6}

Other bug fixes--

Some array CONST use was not running correctly in the PC emulator, most but not all have been fixed.

[YahooArchive]

>from the comment line
>When you load a program, you don't show how much space is left and that's a bad
thing.
>e.g. 24K/64K used or some such nonsense with actual bytes or words e.g.
2048/8192 bytes used.

I thought it was a good suggestion, so there's a new compiler out there that
does that 8.14b (in the files section here)

sample--
ARMbasic[8.14b] on the PC Copyright 2012, Coridium Corp.
*+*+*+*+*+*+
... (12.13K code + 7.63K string)/96K 0.01/9K data programmed

Which shows the amount of Flash and RAM used vs available.

Some notes, when I turned this on I realized we could expand the SuperPRO code
space to 96K. Though it took a couple years for someone to go over 32K which
highlighted a bug in the compiler that was fixed then. The SuperPRO splits the
RAM into two 16K separate blocks, which while we could try to use for variable
allocation, no one seems to have hit that limit yet. Again you can access that
unused 16K space with pointers.

[YahooArchive]

Version 8.16c of the compiler is attached here

Per user request, the ADDRESSOF operator accepts CONST arrays.

In order to support that, CONST arrays now allow multiple lines so

Code: Select all
const multi = {0,&H11,&H22,&H33
,&H44,&H55,&H66,
&H77,&H88,&H99
}

if *(addressof multi +(9<<2)) = multi(9) then print OKmsg else print FAILmsg

const multi = {0,&H11,&H22,&H33
,&H44,&H55,&H66,
&H77,&H88,&H99
}

if *(addressof multi +(9<<2)) = multi(9) then print OKmsg else print FAILmsg

is now allowed

But the old style of repeating CONST lines to build up larger arrays will no
longer work. The reason for this is the original method built the constants in
reverse order assigned in the constant/string space. Now they are build in
normal (ascending in memory) order. A warning has been added to flag possible
old style declarations.

Other things that were fixed

I/O(3) was allowed by the compiler in error, as it was not checking all the new
compound operator errors
x and not(1<<3) is allowed again, this was changed when floating point was
added.

To try this out, download the file and replace the version in the /Program Files
(x86)/Coridium directory

[basicchip]

The latest version

ARMbasic.exe

ARMbasic 8.34h

(135.38 KiB) Downloaded 475 times

[basicchip]

A new compiler is available. For one of our OEM customers we ported code from an AVR to an LPC4078, and in the AVR code there were lots of byte and 16bit (half word) references. To maintain compatibility with that code and not add a big overhead, RD_BYTE, RD_HALF, WR_BYTE and WR_HALF functions were added to the compiler. These are compiled inline so they are quite fast.

In this OEM's code they allow in field updates to their base code, which we support with the __MAP__ statement, which allows you to overwrite a secondary space with an end user code and not disturb the main BASIC program. We adjusted the operation of this from the original form.

In addition we found a compiler bug that reading P0(x) on M0 and ST parts was not correctly compiled. This has been fixed, no one reported it as most likely they were using IN(x) instead.

version 9.36f of ARMbasic

ARMbasic.exe

(135.88 KiB) Downloaded 404 times