#header-inner {background-position: right !important; width: 100% !important;}

'Ola AH' Programming Language: Data Types.

(page in making).




There will be 128-bit & 256-bit data types in 'Ola AH' Programming Language.

256-bit processors could be used for addressing directly up to 2256 bytes. Already 2128 (128-bit) would greatly exceed the total data stored on Earth as of 2010, which has been estimated to be around 1.2 zettabytes (over 270 bytes).

There won't be need for adressing that much of memory for many years, perhaps not in this life at all.

But i think there's good chance that sooner or later there will be support for 256-bit operations, included in 64-bit processors, perhaps in specialized processors. Operations on 256-bit numbers have uses in cryptography, perhaps in other fields as well.

256 bits is a common key size for symmetric ciphers in cryptography, such as Advanced Encryption Standard.

There's idea of 'Very long instruction word (VLIW)', instructions that operate on 256-bit numbers.

'Ola AH' should use support of 256-bit processor operations, this is enough of reason to use 256-bit long data types, in my opinion.


Data Types in 'Ola AH' Programming Language can be:
- constants,
- enumerations,
- primitive variables,
- object variables,
- collection variables,
- variables of a 'var' type that abstracts over primitives, objects & collections.


--
A note:

Why there are decimal (BCD-notation-based) datatypes in 'Ola AH' Programming Language?

Let's remember that 'Ola AH' will allow both for high-level as well as for low-level programming approaches as a part of the design.

BCD (Binary Coded Decimal) notation is easy to read, and still supported by processor & assembler instructions.

More than that, i plan to use BigDecimal datatype with a Fractional datatype - there will be option to 'convert' a Fractional number to BigDecimal number very precisely (with the fraction part), and still have human-readable value.

This will have applications both with High-Level, as well as with Low-Level approach.

BigDecimal numbers will be 'convertible' to arrays of numbers written in the BCD notation, for the convenience of low-level programmers.


Fractional numbers are numbers represented as a serie of fractions, where nominators and denominators are BigInteger numbers.

There will be option to 'fold' the serie (sum) into a single fraction, or 'unfold' a fraction into a serie (sum) of 'smaller' fractions.

Fractional numbers will be as precise as we want, and will 'reform' themselves into a simple form after every arithmetic operation - using 'fold', 'simplify' & 'unfold' operations.

This is expensive processor-time- & memory- wise, but very simple & precise.

When we'll want to convert a Fractional number into a BigDecimal, precision loss associated is reduced to only one operation - this is good news, i think.


For an 'unfold' operation hint, see if You wish or need: Factor Prime.

(We factor nominator with 'limit' equal to nominator, then split it into a serie. Then we try dividing each of fractions of the serie by prime numbers used in nominator to simplify equation).

No comments:

Post a Comment