It was thus said that the Great Iggy Drougge once stated:
Cameron Kaiser skrev:
Besides, why not steal such stuff from BASIC ROM?
On the C64, print a string
from memory by setting A/Y to the localtion and jsr $ab1e, and use the
routine at $bdcd that LIST uses to print line numbers for 16-bit unsigned
int.
By all means, but then you're just programming BASIC in an awkward way. BASIC
has a print statement, assembly has not. OTOH, neither does C. =)
It really depends upon what you mean by ``print statement.'' Yes, the
language specification for BASIC (whatever specification exists) does
include a language element called ``PRINT'' (just as Pascal has WRITE and
WRITELN) and technically, the C language doesn't have such an element. But
... and this is the crucial part here ... if you are programming under ANSI
C (and most C compilers, if not all, in active use today) you have the
Standard C Library (if it doesn't come with an implementation of the
Standard C Library, it can't be considered an ANSI C compiler), of which you
then have the library function printf().
And yes, if you consider ANSI C as a whole, then it *does* have a language
element for printing; it just happens to be written in C [1]. Now, whether
you actually *use* the Standard C Library is up to you. But for starting
out, you can consider C having a language element for printing [2].
Now, getting back to your assertion that Assembly has no print
statement---that's a straw man if I ever saw one. It really depends upon
the platform you are programming for if there is a system facility for
printing. On the Amiga, you have RawDoFmt() (or rather, _LVORawDoFmt(a6)
where a6 contains the Exec library base address) for printing purposes, and
it's flexible enough to print to files, the screen, memory, serial port,
parallel port, or where ever you want the data to go:
move.w #32,-(a7)
pea name(pc)
lea msg(pc),a0
move.l a7,a1
lea stuffChar(pc),a2
lea buffer(pc),a3
move.l _execbase,a6
jsr _LVORawDoFmt(a6)
add.w #10,a7
...
stuffChar move.b d0,(a3)+
rts
...
name dc.b 'Sean Conner',0
msg dc.b 'Hi, I am %s and I am %d years old',0
buffer dcb.b 4096,0
Under Unix, you actually have access to the Standard C Library for
assembly programming (you just link it in). So there, you can do (for an
Intel based Unix, using Nasm):
push dword #34
push dword #name
push dword #msg
call _printf
add esp,12
name db 'Sean Conner',0
msg db 'Hi, I am %s and I am %d years old',0
Not exactly rocket science here. And you might say that you're just
programming AmigaOS or Unix in an awkward way, but no matter what, if you're
not used to Assembly, it's going to look awkward. And you don't learn
assembly in a vaccum---you learn for a particular chip on a particular
system and you will generally have documentation for doing I/O. You might
not have formatted I/O, but you can generally do I/O and part and parcel of
learning assembly is learning how to do things like divide/multiply by 10
(for decimal output), or give up on that and learn how to read octal or hex
*real* quick 8-)
From your messages, I get the feeling you don't like Assembly all that
much ...
-spc (I'll claim the Amiga code as on topic 8-)
[1] The Lattice C compiler for the Amiga will scan the format string
given to printf() and if it determines that it can be handled by
the Exec routine RawDoFmt() (which doesn't support floating point
or some of the more esoteric aspects of printf()) then that routine
will be called instead of the Lattice C implemenation of printf().
Exec is written in 68k Assembly (or at least it was when I was
activetly writing code on the Amiga) so that's why I mention this
exception.
[2] You can write your own printf() routine and it will mask the
Standard C Library implementation, but don't expect your program
to work, as that invokes undefined behavior.
[3] You have to provide a routine that will be called per character
to do the actual I/O, but that can be as simple as stuffing the
character into memory somewhere, much like sprintf() in C.