biged / atalan Goto Github PK

 If comparing against value and there are only two options and one of them is ZERO, always compare against zero. 

   lda STRIG
   cmp #button__state__pressed
   jne _lbl3

Try to compile this:

z=1
"[z][z]"

Atalan for Atari2600?

It would be nice to write some demos for this platform.
There is a lot of knowledge around there.

What do you think about it?

Based on rules with multiple instructions patterns.

:proc a:byte b:byte
        ""

t 4

This segfaults trying to get notexistent variable:


#0  0x0000d90d in VarIsTmp (var=0x0) at variables.c:188
188     return var->name == TMP_NAME;
(gdb) bt
#0  0x0000d90d in VarIsTmp (var=0x0) at variables.c:188
#1  0x0000c32c in PopTop () at parser.c:2416
#2  0x0000c3a1 in ParseCall (proc=0x1153d0) at parser.c:2432
#3  0x0000c5c3 in ParseId () at parser.c:2480
#4  0x0000c8af in ParseCommands () at parser.c:2558
#5  0x0000c99f in Parse (name=0xbfffe6fc "t6", main_file=1) at parser.c:2593
#6  0x0000673b in main (argc=5, argv=0xbffff764) at main.c:172

It may even be reported as hard error.
It should be probably done in value optimization.

When using modulo 8 in sieve, results were not correct.
Replacing it by and #7 resolved the error.

There is an issue, that optimiser (unfold constants module) replaces:

lda #1
lsr a

to 

lda #0

which is wrong, because the carry flag is not set after optimisation.

I know, that this is problem with optimizer architecture which does know 
nothing about processor flags and easily overridden by new div rule.

But there's an issue 20 which is unsolvable this way, I think.

This loops forever during compilation, no matter what arg is, giving
t15(1) syntax error: expected string specifying file name
error

const t1:array = file("")

When generating identifier name in emit, convert non-alphanumeric characters to 
it's ascii values in hexadecimal ('$+' => x24x2b)

Optimize jump to jump as direct jump.

stars.atl (currently with label _lbl10) would be improved by this.

Variable set but not used will be reported as warning (it will get removed by 
optimizer anyway).

Tihis compiles to wrong asm.
there are empty sta statements and warning:

SDLSTL equ 560
   org $2e0
   dta a($2000)
   org $2000
;### t12.atl(5) SDLSTL = dl
   lda #<dl
Internal error: don't know how to emit array element (line 7)
   sta 
   lda #>dl
Internal error: don't know how to emit array element (line 7)
   sta +1
   jmp *
   icl 'atari.asm'

It is new function in common.c returning path, where the atalan executable file 
is located.
Windows have special version, default is path taken from argv[0].

It this path is guaranteed to be absolute on unix, no other modifications 
should be necessary (maybe some testing).
On windows, the path is absolute only if some relative path was not specified.

Jakub, can you please, test and possibly implement this?
Thank You

Using an apostrophe in a string printed on 
screen made the compiled and running program crash (at least on emulator, I 
didn't check this on real Atari). 

Problem with binary operations and addressing tables, for example.

const mask:array(8) = ($fe,$fd,$fb,$f7,$ef,$df,$bf,$7f)
tab:array($200) of byte
k:word

for k:0..$1ff
    tab(k) = mask( k and 7 )

for i:0..255
    "[i]"

produces endless loop

return will return from procedure.
If there are output arguments defined, it is possible to specify them as 
arguments to return.

(So return is similar to procedure call).

Now only integers are supported or name of type.
We may parse expression, then check, that there is .. following.

If it is, we parse interval, if not, there should be name (which we can detect).

Support array lower index different that 0.

What steps will reproduce the problem?
1. try to compile attached file 
2. when MAX_LINE_LEN is much higher, problem dissapears
3. problem dissapears also when raising exception (InternalError for ex) when 
line is too long.

Problem dissapears but still exists.
Parser tries to do something and does the segmentation fault.

I have printed line read by  ReadLine and got:
LINE[[]]
line read, goto retry
1
2
3
4
4
LINE[[f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, 
$80 , $4f, $10, $80 , $4f, $10, $80 , $4f, $10, $80 , $4f, dl
]]
line read, goto retry
Segmentation fault


What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

Describe how to define multiple pieces of memory.

Implement support for boolean types.
Bool types can be used in a simplified way in conditions (if true then ...)

Bool type is recognizes by having named value 'true' or 'false'.

One byte and two byte signed integers.

Possibility to define character output routine.

draw_char c:_a =
   ...

output'routine draw_char

This should become ldx #0.
Currently this will not optimize, even if lda #0 would no longer be needed.

Example is in stars.atl.

There are both of them in the reference. Is it right?

ptr does not work as adr does.

Possibly even passing scope argument as first parameter of function.
Problem: type of the argument is not known at this moment, so it is not 
possible to correctly parse using context.

there is many bugs (for example longer expressions). Fixing them has higher 
priority than new features IMHO :)

I have prepared fifteen.atl to show this problem, because I could not manage to 
separate this.

There are two procedures:
drawmainscreen
and copyblock invoked from drawmainscreen.

They are loopping because of memory conflict:

_s19__i equ 128

and

copyblock__xbm equ 128

Revision 82

The copyblock changes "i" variable above.

When you fix this, I'll continue in trying to make succesful compile of 
fifteen.atl

Instruction Combining

At the source code level, combine two statements into one statement. At the IL 
(Intermediate Language) level, combine two instructions into one instruction.

Example:

In the code fragment below, the two post-increment statements can be combined 
into one statement.

int i;

void f (void)
{
  i++;
  i++;
}

The code fragment below shows the function after the two post-increment 
statements have been combined into one statement.

int i;

void f (void)
{
  i += 2;
}

This compiles, but there is one - byte garbage after the array (look in asm) - 
the last element is repeated.

const t1:array = 1 2 3 4 5
""

Currently it is possible to specify only variable names in expressions.
Full expressions would be very nice.

There is no way to pass the array into proc, or am I wrong?

I would like to have several bitmap buffers and copy parts of them into the 
main screen and use for all of them one procedure.

Use syntax @name to define variables trashed in external function directly in 
header.

< is in
> is out
@ is trash

Try to compile attached file to xex
Next try to compile to asm and look into.
Everything is ok (syntax) with this file, but it does not compile under mads.
It does compile when you put inc 'atari.atl' at the end of file, anyway.

There is the bug that optimiser changes the result.

With no optimisations the result is good.

What with it?
Why it is not in the projests.txt?

By compile attached file there is error. With optimizations off there is no 
error.

It would be nice to have logical xor (for testin purposes)

The compiler segfaults on source 

a(0)=1

result from gdb:

(gdb) bt
#0  0x0000a036 in ParseExpression (result=0x115170) at parser.c:944
#1  0x0000a0cf in ExpectExpression (result=0x115170) at parser.c:967
#2  0x0000b816 in ParseAssign (mode=MODE_VAR, submode=SUBMODE_EMPTY, 
to_type=0x0) at parser.c:2026
#3  0x0000c5b1 in ParseId () at parser.c:2490
#4  0x0000c8af in ParseCommands () at parser.c:2558
#5  0x0000c99f in Parse (name=0xbfffe6dc "t3", main_file=1) at parser.c:2593
#6  0x0000673b in main (argc=5, argv=0xbffff744) at main.c:172

It is local variable in macro.
We must not count usage count of macro variables.

for i:0..5 produces loop 0 1 2 3 4 5

for i:0..500 produces loop 0 1 2 .... 498 499

Develop support for multiple platforms.
Atmos platform will be the first.

Make sieve of Eratosthenes compile on Atmos.

I have added one rule in m6502.atl to get address assignments to work (rev 98)
Unfortunately, optimizer cuts-out those assignments.

You can see this in currentbuf assignments in changepicture func.

So the fifteen does not compile with optimization on. With off it does.

Anyway, good work with optimizer (almost 1 kB cut-out !).

t:proc c:card =
        "[c]"
z:card
z=260
t z*8
z=z*8
t z

gives
32
2080

when compiling:

const t1:array = 1 2 3 4 5

there is missing closing parenthesis?

When there is many calculations, many temporary variables are placed on page0, 
but there is no checking. In result this collides with stack.

In case basic block has a single exit edge that targets other basic block with 
a single entry edge the basic blocks can be merged. We perform code reordering 
when needed.

We need to merge them.

Now it's hardcoded.