First steps - procedures - looking for a good push forward right direction

[pirx]

Hello!

I am looking at Atalan with a real interest as it seems to be THE
language I was looking for. And as long as I am doing simple stuff
everything works like I expected, but when I try to move a bit
further, I am stuck. I suppose I do not understand the idea and
therefore I am trying to do things the wrong way.

This letter is to ask for some guidance and possibly an explanation
how do things correctly.

An example proc:

s@$8000:array(0..39,0..23) of byte

tst:proc x,y:byte >val:byte =
val=s(x-1,y-1)

The above proc does not compile with a message:
"Internal error: no rule for translating instruction
sub _22, _24, 1"

This version:
tst:proc x,y:byte >val:byte =
val=s(x+1,y+1)

Gives:
"Internal error: no rule for translating instruction
let _49, s((_22,_24))"

I suppose it is rather my abuse of the language. Are values passed to
proc unmodifable? I am misunderstanding something?

BTW - "Procedures" section of the Reference seems to be a bit
misleading with "<" and ">". Maybe temporarily you could move language
Reference to Wiki, I would be able to mend some pieces myself.
Additionally the language screams for more examples, e.g. tere are
very few (1?) examples of working proc on the page.

Keep it up!!!

pawel /pirx/ kalinowski

[rudla]

On Mar 20, 3:56 pm, pirx <pawel.kalinow...@gmail.com> wrote:
> Hello!
>
> I am looking at Atalan with a real interest as it seems to be THE
> language I was looking for. And as long as I am doing simple stuff
> everything works like I expected, but when I try to move a bit
> further, I am stuck. I suppose I do not understand the idea and
> therefore I am trying to do things the wrong way.
>
> This letter is to ask for some guidance and possibly an explanation
> how do things correctly.

Thanks.
I'm trying to create a language that will be a real fun to work with.
Atalan is in dire need of users. I believe it is currently adequately
mature considering features
and very good considering optimizations, but there are lot of rough
edges considering
errors.

I will try to provide you with as much help as possible. Please feel
free to ask for help or post
an error to source code repository (I know you know how :-) quickly.

>
> An example proc:
>
> s@$8000:array(0..39,0..23) of byte
>
> tst:proc x,y:byte >val:byte =
>     val=s(x-1,y-1)
>
> The above proc does not compile with a message:
> "Internal error: no rule for translating instruction
>    sub _22, _24, 1"

That would be an error. I would not program it differently. This will
probably have something to do with
relatively new optimization of passing the arguments in registers.
I will check it out.
I am trying to implement as many optimizations as possible to generate
the best code possible. Unfortunately optimizations
are very prone to introducing errors in generated code (often
resulting with the internal error mentioned above).

I recently created con6502 platform to enable creating of unit tests
and help me fight this problem, so I hope the situation will
improve in th future.

>
> This version:
> tst:proc x,y:byte >val:byte =
>     val=s(x+1,y+1)
>
> Gives:
> "Internal error: no rule for translating instruction
>    let _49, s((_22,_24))"
>
> I suppose it is rather my abuse of the language. Are values passed to
> proc unmodifable? I am misunderstanding something?
>
> BTW - "Procedures" section of the Reference seems to be a bit
> misleading with "<" and ">". Maybe temporarily you could move language
> Reference to Wiki, I would be able to mend some pieces myself.
> Additionally the language screams for more examples, e.g. tere are
> very few (1?) examples of working proc on the page.
>
> Keep it up!!!

I certainly will :-) I will give you access to source code repository,
so you can improve documentation (or anything else) directly.
That would be great think.

>
> pawel /pirx/ kalinowski

[Jakub Husak]

Pirx,

first try to turn optimizations off (-o 0).
The code is about 20%longer, but usualy works in predictable way.

This example would work better with assigning to temp variables or
prepare plain variables (no expressions in array access)

So

> tst:proc x,y:byte >val:byte =
> val=s(x-1,y-1)
>
> The above proc does not compile with a message:
> "Internal error: no rule for translating instruction
> sub _22, _24, 1"

would become:

tst:proc x,y:byte >val:byte =

dec x
dec y
val=s(x,y)

In the second example double brackets are confusing me... No idea how
to write compilable code, but try the idea from the first example.

There is m6502.atl file around there in the code, look into this. This
is rather simple and self-describing syntax, so you could check the
rule existence. If not, you can write it by yourself.

2011/3/20 rudla <rudla...@gmail.com>:

--
Pozdrawiam

Kuba Husak

[rudla]

Expressions in array indexes are not the problem.
The problem is, that this is too vaguely type specified for Atalan to
correctly handle right now.

You need to specify the input arguments more precisely. For example:

tst:proc x:1..39,y:1..23 >val:byte

Otherwise Atalan deduces, that type of array index is -1..254 and it
does not support indexing with negative indexes. (There should be
appropriate error message, of course!)

If you tell him, that real range that can be specified is 1..38
(which, by the way may help you detect some nasty errors later), it
will deduce the
type 0..38 and that is viable index.

The double brackets are an artifact of Atalan trying to manipulate the
indexing code in some way and try to find rules for the manipulated
code.


Rudla

On Mar 21, 11:03 am, Jakub Husak <jakub.hu...@gmail.com> wrote:
> Pirx,
>
> first try to turn optimizations off (-o 0).
> The code is about 20%longer, but usualy works in predictable way.
>
> This example would work better with assigning to temp variables or
> prepare plain variables (no expressions in array access)
>
> So> tst:proc x,y:byte >val:byte =
> >     val=s(x-1,y-1)
>
> > The above proc does not compile with a message:
> > "Internal error: no rule for translating instruction
> >    sub _22, _24, 1"
>
> would become:
>
> tst:proc x,y:byte >val:byte =
>     dec x
>     dec y
>     val=s(x,y)
>
> In the second example double brackets are confusing me... No idea how
> to write compilable code, but try the idea from the first example.
>
> There is m6502.atl file around there in the code, look into this. This
> is rather simple and self-describing syntax, so you could check the
> rule existence. If not, you can write it by yourself.
>

> 2011/3/20 rudla <rudla.ku...@gmail.com>:

[pirx]

Kuba, Rudla, thanks a bunch, this is exactly what I needed to know.

> tst:proc x:1..39,y:1..23 >val:byte

This is what I thought might help, but then somehow got distracted by
something different - using evaluations in range definition, e.g.:

const sW=40 sH=24
tst:proc x:1..sW-1,y:1..sH-1 >val:byte

or even:
const sW=39 sH=23
tst:proc x:1..sW,y:1..sH >val:byte

Best regards,

pawel /pirx/

[pirx]

Ah, forgot the question - is such use of const and compile-time
evaluation intrinsically faulty in Atalan or it might be OK in the
future?

Best,

pirx

[rudla]

Yes, it is planned to work (and it actually does in some cases).
However, the Atalan way of doing this would be more like to define
type for the range:

type
scrx:0..39
scry:0..23
cellx:1..38 ;or scrx.min+1..scrx.max-1 in future
celly:1..22

tst:proc x:cellx, y:celly >val:byte

Rudla