ANNOUNCE: ATALAN - new programming language for 6502

rudla.kudla · Post by **rudla.kudla** » Tue Apr 20, 2010 4:11 pm

Hi, I would like to introduce new programming language for 6502 - ATALAN, I'm developing.

It is optimizing compiler.

You can find out more on http://atalan.kutululu.org

It is still work in progress, but it already compiles some small example programs for 8bit ATARI computers (you can use for example ALTIRRA emulator to run the examples).

Rudla Kudla

HansO · Post by **HansO** » Wed Apr 21, 2010 10:53 am

rudla.kudla wrote:

Hi, I would like to introduce new programming language for 6502 - ATALAN, I'm developing.

Rudla Kudla

Very interesting!

kc5tja · Post by **kc5tja** » Thu Apr 22, 2010 2:14 am

rudla.kudla · Post by **rudla.kudla** » Thu Apr 22, 2010 9:11 am

Do you mean the site is not working?
I clicked it 10 seconds ago and it was working...

BigDumbDinosaur · Post by **BigDumbDinosaur** » Fri Apr 23, 2010 2:29 am

The site was up when I clicked the link.

kc5tja · Post by **kc5tja** » Sun Apr 25, 2010 3:29 am

When I accessed it previously, I had received a 404 error. However, it is working for me now.

rudla.kudla · Post by **rudla.kudla** » Fri Mar 18, 2011 9:00 pm

Hi.

I just wanted to report, that Atalan project is still alive and kicking.
Atalan is becoming quite usable and has many nice features and waste (and still growing) range of optimizations.

Atalan can be easily targeted to any 6502 based platform.

So if you are interested, look at http://http://atalan.kutululu.org/.

Source code is available at http://code.google.com/p/atalan/.

Rudla

BigEd · Post by **BigEd** » Fri Mar 18, 2011 10:09 pm

Nice project (open source, cross platform, docs and examples) - well done and thanks!

(Edit: here's a link to "6502 Simulator platform by Michal Kowalski" because people are having trouble finding the new location.)

rudla.kudla · Post by **rudla.kudla** » Sat Mar 19, 2011 5:46 pm

I have added support for 6502 Simulator platform by Michal Kowalski.

It is now possible to compile applications and run it using the simulator.

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Mar 23, 2011 10:59 pm

Hi R.K.

I am software (except 6502 ML/assembly) ignorant. Could you explain your hard work please, on how you took advantage of M.K.'s assembler?
Could you show us an example on how to use what you've made?

Thanks!

rudla.kudla · Post by **rudla.kudla** » Fri Mar 25, 2011 9:54 pm

Hi,

basic info can be found at http://atalan.kutululu.org/sim6502.html

I'm not using the M.K. assembler. Simulator is capable of loading XEX binary file, which s what Atalan generates for this (6502 Simulator) platform.

With some extra work, generated source could be probably M.K. assembler compatible.

ElEctric_EyE · Post by **ElEctric_EyE** » Fri Mar 25, 2011 11:56 pm

I'll definately try to use it when I get my 6502 system up and running... How do you think your compiler would work for graphic routines, e.g. a typical Basic sin(x)?

rudla.kudla · Post by **rudla.kudla** » Sat Mar 26, 2011 2:22 pm

If I find some routines for trigonometric functions, they may be added.
Trouble is, currently Atalan supports just integers (no floating point numbers), so this would be of limited use directly.

I was thinking about support in compile phase, where it would be possible to specify table calculated using some defined expression (including sin, cos, etc.) and use this table in runtime.

Something like:

const sini:array(0..359) of -127..127 = sin(#/2*PI) * 127

and later in code sini(180) could be used to get sinus.

GARTHWILSON · Post by **GARTHWILSON** » Sat Mar 26, 2011 6:46 pm

Quote:

If I find some routines for trigonometric functions, they may be added.
Trouble is, currently Atalan supports just integers (no floating point numbers), so this would be of limited use directly.

Floating-point is not needed nearly as much as we all initially tend to think. Scaled-integer math is far more efficient and works fine for trig, log, square-root, and other functions. I started a topic on it here (really more of a series of articles that people could comment on and ask questions since it's a forum) but like so many other projects, I never finished it.

For 16-bit precision, sin & cos can be calculated accurately with just use the first four terms of the infinite series, with the coefficients tweaked slightly to compensate for the fact that you're not using more terms. You just calculate them for the first 45°, and from that you can get the rest of the circle. The output will usually be accurate to all 16 bits, and the worst error I've found in my testing is 1 lsb high. For scaling, the input angle is represented by $10000 being the whole circle, so for example 90° is 4000H, 45° is $2000, 1 radian is $28BE etc., giving you .0055° resolution, and the wrap-around is perfect (ie, 359°+2°=1° and so on). The output of -1 to +1 is scaled by $7FFF if you want maximum resolution, giving a range of -$7FFF to +$7FFF so the granularity is .0000305 if you're stopping at 16 bits.

For TAN, you just return both SIN and COS since otherwise you have the problem that TAN has this nasty habit of going to ±infinity at ±90°.

Arctan can be interpolated accurately from a surprisingly small table. It works much better than X(1+BX²)/(1+CX²)-DX^^6, not to mention the infinite series which does not converge anywhere nearly as quickly as it does for sin & cos! A table of 16 16-bit numbers, with linear interpolation, gives a maximum error of <.02° if the table entries are tweaked slighly to minimize the maximum error instead of just putting in the straight arctan's. Doubling the size of the table makes the accuracy skyrocket. Without digging up my notes, I can't remember if it makes it four times or eight times as accurate, but the point is that you don't need a big table. Again, you start with just the first 45°, and get the rest from that. Resolution is about .007° worst case (near 0°). This again is if you're stopping at 16 bits of scaled-integer representation.

Logs and antilogs can be interpolated from relatively small tables too if you do them in base 2 (not e, not 10, etc.) and convert from there.

Of course if you have a couple of megabytes for big tables, you can have all the values pre-calculated and just look them up quickly and get every last bit accurate. I have these tables calculated and sitting in Intel hex files but have not used them yet. [Edit, June 2012: They are now published at http://WilsonMinesCo.com/16bitMathTables/index.html ]

Obviously I did not mention all the functions, but the above should be convincing enough that lack of floating-point is hardly a handicap. Floating-point burdens the processor with the job of keeping track of the decimal point during run time. Fixed-point and scaled-integer math puts the burden on the programmer during programming time (which isn't as bad as it sounds, you'll find with experience) and lets the computer be much more efficent at run time.

bogax · Post by **bogax** » Sun Mar 27, 2011 6:16 am

GARTHWILSON wrote:

Arctan can be interpolated accurately from a surprisingly small table. It works much better than X(1+BX²)/(1+CX²)-DX^^6, not to mention the infinite series which does not converge anywhere nearly as quickly as it does for sin & cos! A table of 16 16-bit numbers, with linear interpolation, gives a maximum error of <.02° if the table entries are tweaked slighly to minimize the maximum error instead of just putting in the straight arctan's. Doubling the size of the table makes the accuracy skyrocket. Without digging up my notes, I can't remember if it makes it four times or eight times as accurate, but the point is that you don't need a big table. Again, you start with just the first 45°, and get the rest from that. Resolution is about .007° worst case (near 0°). This again is if you're stopping at 16 bits of scaled-integer representation.

Logs and antilogs can be interpolated from relatively small tables too if you do them in base 2 (not e, not 10, etc.) and convert from there.

Somewhat tangential to this discussion but here's a moderately interesting paper.

http://www.ac.usc.es/system/files/gac2005-j02.pdf.gz

It's hardware oriented.

My version of "...efficient evaluation of the second-degree polynomial
(using a specialized squaring unit.." would be leveraging a table of squares,
which you might have just lying around if you were using a quarter-
square multiply.

High-Speed Function Approximation using a Minimax Quadratic Interpolator

Abstract
A table-based method for high-speed function approximation in single-precision floating-point format is presented in this paper. Our focus is the approximation of reciprocal, square root, square root reciprocal, exponentials, logarithms, trigonometric functions, powering (with a fixed exponent p), or special functions. The algorithm presented here combines table look-up, an enhanced minimax quadratic approximation, and an efficient evaluation of the second-degree polynomial (using a specialized squaring unit, redundant arithmetic, and multioperand addition). The execution times and area costs of an architecture implementing our method are estimated, showing the achievement of the fast execution times of linear approximation methods and the reduced area requirements of other second-degree interpolation algorithms. Moreover, the use of an enhanced minimax approximation which, through an iterative process, takes into account the effect of rounding the polynomial coefficients to a finite size allows for a further reduction in the size of the look-up tables to be used, making our method very suitable for the implementation of an elementary function generator in state-of-the-art DSPs or graphics processing units (GPUs).