AnyCPU :: View topic - difference between address registers and data ones

Vladimir wrote:

But, the DS directive works differently in the vasm assembler: it fills the given memory area with zeros. It turns out that these locations are initialized with zeros. I've never used EASy68K and I don't understand what uninitialized memory locations in a.out file should look like? After all, these uninitialized locations should still occupy some part of the output file size?

Code:

    cpu   68000
    org   $400
    dc.b  $11, $12
    org   $404
    dc.b  $21, $22
    ds.b  2
    dc.b  $31, $32

Code:

PLIST/C V1.42 Beta [Bld 243]
(C) 1992,2023 Alfred Arnold

Code-Type   Segment    Start-Address  Length (Bytes) End-Address
----------------------------------------------------------------
680x0         CODE      00000400          0002       00000401
680x0         CODE      00000404          0002       00000405
680x0         CODE      00000408          0002       00000409
creator : AS 1.42 Beta [Bld 243]/i386-unknown-win32

altogether 6 bytes CODE

Code:

P2BIN/C V1.42 Beta [Bld 243]
(C) 1992,2023 Alfred Arnold
Deduced address range: 0x00000400-0x00000409
prog.p==>>prog.bin  (6 Bytes)

Author:	Vladimir [ Thu Apr 21, 2022 2:06 pm ]
Post subject:	Re: difference between address registers and data ones
Thanks BigEd. I corrected the settings in the smartphone and now the notifications are visible.

Author:	cjs [ Sat May 06, 2023 5:30 pm ]
Post subject:	Re: difference between address registers and data ones
Vladimir wrote: But, the DS directive works differently in the vasm assembler: it fills the given memory area with zeros. It turns out that these locations are initialized with zeros. I've never used EASy68K and I don't understand what uninitialized memory locations in a.out file should look like? After all, these uninitialized locations should still occupy some part of the output file size? In most assemblers DS itself never initialises storage; the zero-filled areas you're getting are due to your output file format. Consider the following, assembled with Macro Assembler AS: Code: cpu 68000 org $400 dc.b $11, $12 org $404 dc.b $21, $22 ds.b 2 dc.b $31, $32 This will produce an output file ending in .p, and if you run AS's plist it, you'll get: Code: PLIST/C V1.42 Beta [Bld 243] (C) 1992,2023 Alfred Arnold Code-Type Segment Start-Address Length (Bytes) End-Address ---------------------------------------------------------------- 680x0 CODE 00000400 0002 00000401 680x0 CODE 00000404 0002 00000405 680x0 CODE 00000408 0002 00000409 creator : AS 1.42 Beta [Bld 243]/i386-unknown-win32 altogether 6 bytes CODE As you can see, the .p output format supports multiple sections of memory, each with a start address and length, and here each section is correctly two bytes of data, with nothing in the "empty" areas between them, whether those are due to DS or ORG directives. However, if you create a "raw" binary file from this using p2bin, it prints Code: P2BIN/C V1.42 Beta [Bld 243] (C) 1992,2023 Alfred Arnold Deduced address range: 0x00000400-0x00000409 prog.p==>>prog.bin (6 Bytes) and a hex dump of the file looks like this: Code: 00000000: 11 12 ff ff 21 22 ff ff 31 32 Here you'll note that we've lost the start address, and it had to find something to fill in the unallocated spaces since the output of a raw binary file must be contiguous. So it filled those areas in with $FF. ($FF is the default fill value, since most PROM burners will treat that as "uninitialised data" and not bother burning large sections of the PROM that would just be $FF anyway if not burned, but you can change the fill value with the -l option to p2bin.)

AnyCPU http://anycpu.org/forum/

difference between address registers and data ones http://anycpu.org/forum/viewtopic.php?f=25&t=876	Page 2 of 2

Page 2 of 2	All times are UTC
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/