Variable size/Set: Difference between revisions

=={{header|360 Assembly}}==

The 360 architecture data specifications are:

* Binary interger (H,F)

I2 DS H half word 2 bytes

A4 DC A(176) 4 bytes but only 3 bytes used

* (24 bits => 16 MB of storage)

=={{header|6502 Assembly}}==

Since these are variables, the value given to them (in this case, 0) is the initial value, and can be changed later at runtime. If you don't care what the initial value is, some assemblers allow you to use a "?" where the 0s are.

byte 0 ;most assemblers will also accept DB or DFB

MyWord:

word 0 ;most assemblers will also accept DW or DFW

MyDouble:

For programs that are executed solely from ROM, such as video game console cartridges, you won't be able to use the above method. The assembler can often use an <code>enum</code> or <code>rsset</code> directive to sequentially assign labels to a series of consecutive memory locations in the system's RAM.

VBlankFlag .rs 1 ;$00

soft_PPUCTRL .rs 1 ;$01

soft_SCROLL_Y .rs 1 ;$04

temp_16 .rs 2 ;$05,$06

Assemblers that don't have an <code>enum</code> or <code>rsset</code> directive can use the <code>equ</code> directive instead. This method lets you immediately see what each memory location actually is, but it makes it harder to insert a new one without having to redo all the numbering. Certain 6502 instructions rely on two memory addresses being consecutive.

soft_PPUCTRL equ $01

soft_PPUSTATUS equ $02

soft_SCROLL_Y equ $04

temp_16 equ $05 ;you have to keep track of spacing yourself in this method

While setting a variable's size is easy, getting it isn't possible without knowing it in advance. The CPU does not (and cannot) know the intended size of a variable. There's no enforcement of types whatsoever on the 6502; anything is fair game.

Since these are variables, the value given to them (in this case, 0) is the initial value, and can be changed later at runtime. If you don't care what the initial value is, some assemblers allow you to use a "?" where the 0s are.

DC.B 0

EVEN ;you need this to prevent alignment problems if you define an odd number of bytes.

DC.W 0 ;this takes up 2 bytes even though only one 0 was written

MyLong:

For programs that are executed solely from ROM, such as video game console cartridges, you won't be able to use the above method. The assembler can often use an <code>enum</code> or <code>rsset</code> directive to sequentially assign labels to a series of consecutive memory locations in the system's RAM. Assemblers that don't have an <code>enum</code> or <code>rsset</code> directive can use the <code>equ</code> directive instead. This method lets you immediately see what each memory location actually is, but it makes it harder to insert a new one without having to redo all the numbering. These variables are located in the heap and thus there is no need to use <code>EVEN</code> directives to align this data.

Cursor_X equ $100000 ;byte - only comments can tell you the intended variable size.

Cursor_Y equ $100001 ;byte

tempWord equ $100002 ;word - also occupies $100003

Syntax will vary depending on the assembler you're using, but the following should apply to most assemblers.

.data ;data segment

mov dh, byte ptr [ds:TestValue_00] ;load the value stored at the address "TestValue_00"

For programs that are executed from ROM, such as those on video game cartridges, the above syntax can only be used to define constants. Defining variables will need to be done using <code>equ</code> directives, and you'll need to read the system's documentation to know where the heap is located. For example, the Bandai Wonderswan has its heap located starting at memory address <code>100h</code>.

There is some enforcement of variable sizes, but it's not as strict as most other languages. The two commands above would not have worked had the wrong register sizes been used. However, using the wrong labels is perfectly legal in the eyes of most assemblers.

In fact, data sizes don't matter to the CPU all that much, as the following definitions are all equivalent:

bar word 0,0

The data types are more for the programmer's convenience, so that it's clear how the data should be interpreted.

Data can be organized in a table for better readability; however it has no effect on how the data is structured apart from visually. (The data will be organized in a linear fashion regardless, so it makes no difference to the CPU). The following two structures are the same:

Array2 byte 00,01

If you have a variable of a pre-determined size that isn't 1, 2, or 4 bytes you can use the following to define it:

While it's easy to set a variable's size, getting it is impossible without knowing it in advance. Variables are nothing more than just a section of RAM; the CPU does not (and cannot) know how many bytes your variable is supposed to be.

=={{header|Ada}}==

=={{header|ARM Assembly}}==

Syntax will vary depending on your assembler. VASM uses <code>.byte</code> for 8-bit data, <code>.word</code> for 16-bit data, and <code>.long</code> for 32-bit data, but this is not the norm for most assemblers, as a "processor's word size" is usually the same as its "bitness." I'll use the VASM standard anyway, just because. When defining data smaller than 32-bits, there needs to be sufficient padding to align anything after it to a 4-byte boundary. (Assemblers often take care of this for you, but you can use a directive like <code>.align 4</code> or <code>.balign 4</code>to make it happen.

.align 4

.word 0xFFFF

.align 4

Keep in mind that although you may have <i>intended</i> the data to be of a particular size, the CPU does not (and cannot) enforce that you use the proper length version of <code>LDR/STR</code> to access it. It's perfectly legal for the programmer to do the following:

ADR r1,TestData ;load the address TestData

LDRB r0,[r1] ;loads 0x000000EF into r0 (assuming the CPU is operating as little-endian, otherwise it will load 0x000000DE)

BX LR

TestData:

The reverse is also true; you can point a register to the label of a <code>.byte</code> data directive and load it as a long, which will give you the byte along with the padding that it would receive to keep everything aligned. Generally speaking, you don't want to do this, as it can lead to problems where a register doesn't contain what the code assumes it does. However, being able to ignore typing at will can be advantageous, such as when trying to copy large blocks of consecutive memory, where you can achieve more throughput by copying 32 bits per instruction instead of only 8 or 16.

Variable sizes are in chunks relating to the type of data that they contain. There may also be additional bytes of storage in the variable table that do not show in the dimensions. Typically, strings are allocated in single characters (bytes), so C$(12) in the following example is stored as 12 bytes + additional bytes used for the header in the variable table. In some implementations of basic (such as those that support the storage of variable length strings in arrays), additional terminator characters (such as a trailing Ascii NUL) may also be included. In traditional basic, integers are typically 2 bytes each, so A%(10) contains 10 lots of 2 bytes (20 bytes in total) + additional bytes used for header data in the variable table. Floating point values are typically 8 bytes each, so B(10) holds 10 lots of 8 bytes (80 bytes in total) + additional bytes for header in the variable table:

20 DIM B(10): REM the array will hold 10 floating point values

==={{header|Applesoft BASIC}}===

Using one character variable names, and reusing variables is one way to save on space. The FRE(0) function can be used to houseclean (garbage collect) unused string space. If arrays are not declared with DIM they default to 11 elements in size. PEEK and POKE can be used to operate on byte and bit sized data.

1 PRINT "FLOATING POINT:";:G = 0: GOSUB 9

2 PRINT "INTEGER:";:I0% = 0: GOSUB 9

7 PRINT "ARRAYS OF SIZE 2"

8 PRINT "FLOATING POINT:";: DIM G(1): GOSUB 9: PRINT "INTEGER:";: DIM J%(1): GOSUB 9: PRINT "STRING:";: DIM T$(1): GOSUB 9: END

<pre>

DATA TYPES

{{works with|BBC BASIC for Windows}}

The only way to 'set' the size of a scalar numeric variable is to declare it with the appropriate type suffix:

var% = 1 : REM Variable occupies 32 bits

var = 1 : REM Variable occupies 40 bits

If the task is talking about setting the size of a variable ''at run time'' that is only possible with strings, arrays and structures.

==={{header|IS-BASIC}}===

110 NUMERIC ARRAY(1 TO 100)

120 NUMERIC MATRIX(1 TO 10,1 TO 10)

140 STRING NAME$(1 TO 100)*24

150 STRING LINE$*254

=={{header|C}}==

{{works with|C99}}

Here <var>foo</var> is a signed integer with at least 32 bits. [[wp:stdint.h#Minimum-width integer types|stdint.h]] also defines minimum-width types for at least 8, 16, 32, and 64 bits, as well as unsigned integer types.

int i;

long l;

double d;

/* ... */

Here the use of <code>union</code> results in a datatype which is at least as large as the largest type. Unions are sometimes exploited to just meet a minimum size:

int interesting_datum;

char padding[512];

Here, the application will never access <code>padding</code> nor store anything; the padding is there to make the type large enough to meet some requirement. For instance, so that some third party API function which fills in the object, doesn't write past the end of the memory, when the program is only interested in <code>interesting_datum</code>.

=={{header|C++}}==

{{works with|C++11}} or {{works with|Boost}}

=={{header|D}}==

In D, any variables of static array of zero length has a size of zero. But such data is useless, as no base type element can be accessed.

NOTE: a dynamic array variable's size is always 8 bytes, 4(32-bit) for length and 4 for a reference pointer of the actual storage somewhere in runtime memory.<br>

The proper candidates of minimum size variable are empty structure, 1-byte size data type variable (include <tt>byte, ubyte, char and bool</tt>), and void, they all occupy 1 byte.

ubyte ub ;

char c ;

<tt>bool</tt> is logically 1-bit size, but it actually occupy 1 byte.<br>

<tt>void</tt> can't be declared alone, but <tt>void.sizeof</tt> gives 1.<br>

An empty structure is logically zero size, but still occupy 1 byte.

=={{header|Erlang}}==

Variable sizes are in chunks relating to the type of data that they contain. There may also be additional bytes of storage in the variable table that do not show in the dimensions. Typically, in ERRE strings are allocated in single characters (bytes), so C$[12] in the following example is stored as 12 bytes + additional bytes used for the header in the variable table. Integers are typically 2 bytes each, so A%[10] contains 10 numbers of 2 bytes (20 bytes in total) + additional bytes used for header data in the variable table. Floating point values are typically 4 bytes each, so B[10] holds 10 numbers of 4 bytes (40 bytes in total) + additional bytes for header in the variable table:

DIM B[10] ! the array will hold 10 floating point values

There is also "double" floating point values (8 bytes). Variables of this type use the suffix #.

'''selected_int_kind(R)''', where R is the required decimal exponent range. The return value is the kind type parameter for integer values n such that -10^R < n < 10^R. A value of -1 is returned if R is out of range.

implicit none

write(*, form) "iprec4", kind(n7), r6, range(n7)

Output

<pre>KIND NAME KIND NUMBER PRECISION RANGE

''See also: [[#Pascal|Pascal]]''

{$packEnum 4}

Only a <tt>{$packEnum}</tt> of <tt>1</tt>, <tt>2</tt>, or <tt>4</tt> Bytes can be specified.

{{trans|Ada}}

For task interpretation this follows the spirit of the Ada example included by the task author. In it, an enumeration type is defined from enumeration values, then a storage size--smaller than the default--is specified for the type. A similar situation exists within Go. Defining types from values is called duck-typing, and the situation where a type smaller than the default can be specified exists when a variable is duck-typed from a numeric literal.

import (

fmt.Println("fMin:", unsafe.Sizeof(fMin), "bytes")

fmt.Println("cMin:", unsafe.Sizeof(cMin), "bytes")

Output:

<pre>

=={{header|Haskell}}==

import Data.Int

import Foreign.Storable

task "Int64" i64

task "Int" int

{{out}}

<pre>

* lists can be specified with a minimum size (see below):

=={{header|J}}==

Here, v is specified to have a minimum size. In this case, the minimum size of the content is zero, though the size of the representation is somewhat larger.

=={{header|Julia}}==

for t in types

println("\nFor the 24-bit user defined type MyInt24, size is ", sizeof(MyInt24), " bytes.")

For type Bool size is 1 8-bit bytes, or 8 bits.

For type Char size is 4 8-bit bytes, or 32 bits.

The following program shows the range of numbers which the primitive numeric types can accomodate to enable one to choose the appropriate type:

fun main(args: Array<String>) {

println("A Float variable has a range of : ${Float.MIN_VALUE} to ${Float.MAX_VALUE}")

println("A Double variable has a range of : ${Double.MIN_VALUE} to ${Double.MAX_VALUE}")

{{out}}

=={{header|Modula-3}}==

Note that this only works for records, arrays, and objects. Also note that the size in bits must be large enough to hold the entire range (in this case, 8 bits is the correct amount for the range 0 to 255) or the compiler will error.

3) Nim offers also the possibility to set the size of fields into an object. This is done with the pragma <code>bitsize</code>. For instance, we can specify:

MyBitfield = object

When Nim uses C as intermediate language, the pragma “bitsize” is translated in C bit fields. The previous example will produce something like that:

unsigned int flag:1;

=={{header|ooRexx}}==

=={{header|PARI/GP}}==

Alternately, in the gp interpreter,

=={{header|Pascal}}==

The GPC (GNU Pascal compiler), however, allows for ''integer'' types the specification of a minimum precision:

''See also: [[#Free Pascal|Free Pascal]]''

mpfr (floating point) variables require the precision to be explicitly specified in binary bits, for example if you want PI to 120 decimal places:

{{libheader|Phix/mpfr}}

<span style="color: #008080;">with</span> <span style="color: #008080;">javascript_semantics</span>

<span style="color: #7060A8;">requires</span><span style="color: #0000FF;">(</span><span style="color: #008000;">"1.0.0"</span><span style="color: #0000FF;">)</span>

<span style="color: #7060A8;">mpfr_const_pi</span><span style="color: #0000FF;">(</span><span style="color: #000000;">pi</span><span style="color: #0000FF;">)</span>

<span style="color: #7060A8;">printf</span><span style="color: #0000FF;">(</span><span style="color: #000000;">1</span><span style="color: #0000FF;">,</span><span style="color: #008000;">"PI with 120 decimals: %s\n\n"</span><span style="color: #0000FF;">,</span><span style="color: #7060A8;">mpfr_get_fixed</span><span style="color: #0000FF;">(</span><span style="color: #000000;">pi</span><span style="color: #0000FF;">,</span><span style="color: #000000;">120</span><span style="color: #0000FF;">))</span>

=={{header|PicoLisp}}==

=={{header|PL/I}}==

declare i fixed binary (7), /* occupies 1 byte */

j fixed binary (15), /* occupies 2 bytes */

y float decimal (16), /* occupies 8 bytes */

z float decimal (33); /* occupies 16 bytes */

=={{header|PureBasic}}==

EnableExplicit

EndIf

{{out}}

<br><br>There's effectively no limit for the precision [or length] for REXX numbers (except for memory),

<br>but eight million is probably the practical limit.

numeric digits 100 /*default: 9 (decimal digs) for numbers*/

/* [↑] these #'s are stored as coded. */

=={{header|Scala}}==

println(s"A Byte variable has a range of : ${Byte.MinValue} to ${Byte.MaxValue}")

println(s"A Short variable has a range of : ${Short.MinValue} to ${Short.MaxValue}")

println(s"A Long variable has a range of : ${Long.MinValue} to ${Long.MaxValue}")

println(s"A Float variable has a range of : ${Float.MinValue} to ${Float.MaxValue}")

See it running in your browser by [https://scastie.scala-lang.org/dX0sTLz5Q1ShT8mLL0cv1g Scastie (JVM)].

In Tcl, most values are (Unicode) strings. Their size is measured in characters, and the minimum size of a string is of course 0.

However, one can arrange, via write traces, that the value of a variable is reformatted to bigger size. Examples, from an interactive [[tclsh]] session:

% trace var foo w {format_trace %10s}

% trace var grill w {format_trace %-10s}

% puts "/[set grill bar]/"

% trace var baz w {range_trace 2}

% set baz Frankfurt

=={{header|TXR}}==

Here, the buffer holds eight zero bytes, but 4096 bytes is allocated to it:

Another situation, in the context of FFI, is that some structure needs to achieve some size, but we don't care about all of its members. We can add anonymous padding to ensure that it meets the minimum size. For instance, suppose we want to call <code>uname</code>, and we only care about retrieving the <code>sysname</code>:

The last feature eliminates the need for explicitly setting the precision of numbers having exact

representations, albeit contrary to the convention in physical sciences.

x = mpfr..grow(1.0E+0,1000) # 160 default precision, grown to 1160

a = # 180 bits (not the default 160) because of more digits in the constant

=={{header|Vlang}}==

b := true

i := 5 // default type is i32

println("r_min: ${sizeof(r_min)} bytes")

println("f_min: ${sizeof(f_min)} bytes")

{{out}}

<pre>b: 1 bytes

The programmer cannot specify a minimum size for a Map but can specify a minimum size for a List - in effect the amount of heap storage required to store its elements. This can still be increased dynamically by adding futher elements to the List. Here's an example.

var l = List.filled(10, 0)

// give them different values and print them

// add another element to the list dynamically and print it again

l.add(10)

{{out}}

=={{header|XPL0}}==

string 0; \use zero-terminated strings

char S,

I:= I & ~(1<<29); \stores a 0 bit into bit 29 of the integer

IntOut(0, I>>3 & 1); \displays value of bit 3

Other than arrays and strings, variables are a fixed size. Integers are

Since these are variables, the value given to them (in this case, 0) is the initial value, and can be changed later at runtime. If you don't care what the initial value is, some assemblers allow you to use a "?" where the 0s are.

byte 0 ;most assemblers will also accept DB or DFB

MyWord:

word 0 ;most assemblers will also accept DW or DFW

MyDouble:

For programs that are executed solely from ROM, such as video game console cartridges, you won't be able to use the above method. The assembler can often use an <code>enum</code> or <code>rsset</code> directive to sequentially assign labels to a series of consecutive memory locations in the system's RAM.

tempByte .rs 1

tempWord .rs 2

Assemblers that don't have an <code>enum</code> or <code>rsset</code> directive can use the <code>equ</code> directive instead. This method lets you immediately see what each memory location actually is, but it makes it harder to insert a new one without having to redo all the numbering. When loading from an immediate memory location to a 16-bit register pair (e.g. <code>LD HL,($4000)</code>, the "low register" is loaded with the byte stored at the memory location specified by the operand, and the "high register" is loaded with the byte stored at the memory location after that.

tempWord equ $C001 ;high byte at $C002

While setting a variable's size is easy, getting it isn't possible without knowing it in advance. The CPU does not (and cannot) know the intended size of a variable. There's no enforcement of types whatsoever on the Z80, anything goes. If, for example, you executed <code>LD HL,($4000)</code> and $4000 was <i>intended</i> to be the storage location of an 8-bit value, you'd get the intended value in L and whatever happened to be after it in memory into H. Whether that's a problem or not is up to the programmer, not the CPU.

=={{header|ZX Spectrum Basic}}==

20 DIM b(10): REM this will hold a set of numbers. The fixed number of bytes per number is implementation specific

{{omit from|AWK}}