String literals in asm source code

[James Harris]

What's the most readable way to include string literals in asm source code?



Option 1
========

I usually define string literals in a separate block, like this.

;**********
;
; Data section
;
;**********
section .data
msg_started: db "Operation started", 0
msg_finished_errors: db "Operation finished. Number of errors: ", 0

Then, later,

;**********
;
; Text section
;
;**********
mov ebx, msg_started


The downside to that is that the message can be separated from its use
by a few screens-worth of scrolling.


Option 2
========

To avoid a large separation between def and use one could temporarily
drop to the data section as needed in the middle of other code (I'll use
nops to indicate other executable code).

nop
nop
nop
section .data
msg_started: db "Operation started", 0
section .text
mov ebx, msg_started

The downside of that is it is arguably harder to read (and doesn't deal
with duplicate strings well).


Option 3
========

Or, maybe a macro could effect option 2 - something like the following.
(This is illustrative, not tested code.)

mov ebx, string_literal(db "Operation started", 0)



Of course, code layout is not a major issue but it is one of
convenience; and readability is important. So I wondered what other
people do to incorporate strings in code. What have you found to be the
most readable and easiest to work with?

[Rick C. Hodgin]

Post by James Harris
What's the most readable way to include string literals in asm source code?

I always use:

label:
db 'whatever here',0

Something like that, then reference it by the label name.

[R.Wieser]

James,

Why not put the data segments at the bottom of the code fragments (after its
procedural return I mean) ? That way its close to the code using it, but
not muddying-up the code itself:

;====================
section text
;------------------------------
;Description of procedure

procedure starts

mov ebx, msg_started



ret

;====================
section data
;------------------------------

msg_started: db "Operation started", 0

;------------------------------
procedure ends
;====================

Yes, that, including the ";====" and ";----" is what I'm using myself.
With a number of blank lines between the lower ";===" and the same at the
start of the next procedure (to keep them visually seperated). If needed I
also append a block for some uninitialized data.

And by the way, the reason that the "procedure ends" is below the data
segment is that that way you should be able to use procedure-local labels
for the data too.

Regards,
Rudy Wieser

[James Harris]

Post by R.Wieser
James,
Why not put the data segments at the bottom of the code fragments (after its
procedural return I mean) ? That way its close to the code using it, but

...

Post by R.Wieser
And by the way, the reason that the "procedure ends" is below the data
segment is that that way you should be able to use procedure-local labels
for the data too.

Agreed, that's a pretty good way to go.

[JJ]

Post by James Harris
What's the most readable way to include string literals in asm source code?
Option 1
========
I usually define string literals in a separate block, like this.
;**********
;
; Data section
;
;**********
section .data
msg_started: db "Operation started", 0
msg_finished_errors: db "Operation finished. Number of errors: ", 0
Then, later,
;**********
;
; Text section
;
;**********
mov ebx, msg_started
The downside to that is that the message can be separated from its use
by a few screens-worth of scrolling.

I use this layout in most cases. If the code section is too long, I put the
data section contents in a separate file - as an include file for the main
source code. Considering that I can quickly switch between main and include
files' tab in the text editor. However, I'd do this only after the
development is completed. Otherwise, it'd be troublesome to trace if there's
a compilation error.

Post by James Harris
Option 2
========
To avoid a large separation between def and use one could temporarily
drop to the data section as needed in the middle of other code (I'll use
nops to indicate other executable code).
nop
nop
nop
section .data
msg_started: db "Operation started", 0
section .text
mov ebx, msg_started
The downside of that is it is arguably harder to read (and doesn't deal
with duplicate strings well).

IMO, that's quite a useful layout but, what if there are other parts of the
source code which need to be laid out like that? Does the compiler allows
multiple section declarations with the same section name?

Post by James Harris
Option 3
========
Or, maybe a macro could effect option 2 - something like the following.
(This is illustrative, not tested code.)
mov ebx, string_literal(db "Operation started", 0)
Of course, code layout is not a major issue but it is one of
convenience; and readability is important. So I wondered what other
people do to incorporate strings in code. What have you found to be the
most readable and easiest to work with?

I don't think macros can be used using that kind of syntax for this purpose.
While it may be possible using the proper syntax, it's basically still the
same as Option 2, just simpler. And with the same problem.

[James Harris]

Post by JJ

Post by James Harris
What's the most readable way to include string literals in asm source code?

...

Post by JJ

Post by James Harris
Option 2
========
To avoid a large separation between def and use one could temporarily
drop to the data section as needed in the middle of other code (I'll use
nops to indicate other executable code).
nop
nop
nop
section .data
msg_started: db "Operation started", 0
section .text
mov ebx, msg_started
The downside of that is it is arguably harder to read (and doesn't deal
with duplicate strings well).

IMO, that's quite a useful layout but, what if there are other parts of the
source code which need to be laid out like that? Does the compiler allows
multiple section declarations with the same section name?

Yes, the assembler will allow multiple trips into various sections.

Post by JJ

Post by James Harris
Option 3
========
Or, maybe a macro could effect option 2 - something like the following.
(This is illustrative, not tested code.)
mov ebx, string_literal(db "Operation started", 0)
Of course, code layout is not a major issue but it is one of
convenience; and readability is important. So I wondered what other
people do to incorporate strings in code. What have you found to be the
most readable and easiest to work with?

I don't think macros can be used using that kind of syntax for this purpose.
While it may be possible using the proper syntax, it's basically still the
same as Option 2, just simpler. And with the same problem.

You are right, a different syntax would be needed. I'll post separately
about using macros because they are not working for me.

[Rod Pemberton]

On Fri, 21 Dec 2018 19:49:50 +0000

Post by James Harris
What's the most readable way to include string literals in asm source code?
Option 1
========
I usually define string literals in a separate block, like this.
;**********
;
; Data section
;
;**********
section .data
msg_started: db "Operation started", 0
msg_finished_errors: db "Operation finished. Number of errors: ", 0
Then, later,
;**********
;
; Text section
;
;**********
mov ebx, msg_started
The downside to that is that the message can be separated from its
use by a few screens-worth of scrolling.
Option 2
========
To avoid a large separation between def and use one could temporarily
drop to the data section as needed in the middle of other code (I'll
use nops to indicate other executable code).
nop
nop
nop
section .data
msg_started: db "Operation started", 0
section .text
mov ebx, msg_started
The downside of that is it is arguably harder to read (and doesn't
deal with duplicate strings well).
Option 3
========
Or, maybe a macro could effect option 2 - something like the
following. (This is illustrative, not tested code.)
mov ebx, string_literal(db "Operation started", 0)
Of course, code layout is not a major issue but it is one of
convenience; and readability is important. So I wondered what other
people do to incorporate strings in code. What have you found to be
the most readable and easiest to work with?

I usually just have a single .text section for my assembly code, i.e.,
for small amounts of assembly code, as I prefer C to assembly. The
strings are labeled and placed at the end-of-file. Usually, the label
has sufficient meaning, in English or to me personally, as to not
require (re)reading the string:

.text
mov ebx, msg_op_start
; ...

; at end-of-file:
msg_op_start: db "Operation started", 0
msg_op_fin_errs: db "Operation finished. Number of errors: ", 0


Some other possible options are:

1) inline the string, i.e., place it in the code and jump over it:

jmp nxt
msg_started: db "Operation started", 0
nxt:
mov ebx, msg_started


2) inline the string another way, i.e., place it inbetween routines,
e.g., it could be placed prior to or after any routine, but is more
"readable" IMO prior to proc2 below than after proc1 below:

proc1:
mov ebx, msg_started
; ...
ret

; after proc1
; before proc2

msg_started: db "Operation started", 0

proc2:
mov ebx, msg_started
; ...
ret


3) use a ; comment to describe the string on the code line that uses it:

mov ebx, msg_started ; msg_started is "Operation started"


Obviously, I believe there are disadvantages to each of these. These
are left for the reader to identify, and then choose.


Rod Pemberton

[Kerr-Mudd,John]

On Fri, 21 Dec 2018 19:49:50 GMT, James Harris

Post by James Harris
What's the most readable way to include string literals in asm source code?

Short answer; it depends
I generally like to keep text together (like Option 1) but at the bottom
of the src, YMMV.

Post by James Harris
Option 1
========
I usually define string literals in a separate block, like this.
;**********
;
; Data section
;
;**********
section .data
msg_started: db "Operation started", 0
msg_finished_errors: db "Operation finished. Number of errors: ", 0
Then, later,
;**********
;
; Text section
;
;**********
mov ebx, msg_started
The downside to that is that the message can be separated from its use
by a few screens-worth of scrolling.
Option 2
========
To avoid a large separation between def and use one could temporarily
drop to the data section as needed in the middle of other code (I'll
use nops to indicate other executable code).
nop
nop
nop
section .data
msg_started: db "Operation started", 0
section .text
mov ebx, msg_started
The downside of that is it is arguably harder to read (and doesn't
deal with duplicate strings well).
Option 3
========
Or, maybe a macro could effect option 2 - something like the
following. (This is illustrative, not tested code.)
mov ebx, string_literal(db "Operation started", 0)
Of course, code layout is not a major issue but it is one of
convenience; and readability is important. So I wondered what other
people do to incorporate strings in code. What have you found to be
the most readable and easiest to work with?

[s***@nospicedham.yahoo.com]

Post by James Harris
What's the most readable way to include string literals in asm source code?
Option 1
========
I usually define string literals in a separate block, like this.
;**********
;
; Data section
;
;**********
section .data
msg_started: db "Operation started", 0
msg_finished_errors: db "Operation finished. Number of errors: ", 0
Then, later,
;**********
;
; Text section
;
;**********
mov ebx, msg_started
The downside to that is that the message can be separated from its use
by a few screens-worth of scrolling.
Option 2
========
To avoid a large separation between def and use one could temporarily
drop to the data section as needed in the middle of other code (I'll use
nops to indicate other executable code).
nop
nop
nop
section .data
msg_started: db "Operation started", 0
section .text
mov ebx, msg_started
The downside of that is it is arguably harder to read (and doesn't deal
with duplicate strings well).
Option 3
========
Or, maybe a macro could effect option 2 - something like the following.
(This is illustrative, not tested code.)
mov ebx, string_literal(db "Operation started", 0)
Of course, code layout is not a major issue but it is one of
convenience; and readability is important. So I wondered what other
people do to incorporate strings in code. What have you found to be the
most readable and easiest to work with?
--
James Harris

Re Option 2..

I use nasm -fbin
I control the memory model by how I express the sections.
The 'expression' needs doing once at the beginning, thereafter just indicate the sections.

ex. small model where CS = DS :

all the .text sections are followed by the .data sections and the addressing flows from one through the other.

[SECTION .text align=1 vstart=BiosOffset]
[SECTION .data align=1 vfollows=.text]

[SECTION .text]

jmp near INIT ;; 0. Enter from BOOT ROM or LOADER, as Cold Boot.
.
.
.

[SECTION .text]

Fill_DMA:
CLD

push ES
push DS
pop ES

mov SI, msgTest ;; src = DS:SI
mov DI, Local_DMA ;; dest. = ES:DI
.lp:
LODSB ;; DS:SI++
cmp al,0 ;; ck terminator byte
je .done
STOSB ;; otherwise, AL->ES:DI++
jmp .lp
.done:
mov al, 1Ah ;; ctrl-z text termination
stosb

pop ES

RET

[SECTION .data] ;; 73 bytes, + a null

msgTest: db 'This is string data to test writing to a file, an also test TYPE '
db 'command.',0


[SECTION .text]
.
.
.

So this works for me, maybe suitable for you. (shrug)

Merry Christmas to All..

Steve

[p***@nospicedham.gmail.com]

So I wondered what other people do to incorporate strings in code. What have you found to be the most readable and easiest to work with?

I believe that the most convenient way is not having to invent a unique symbol name for each string, but use the string value itself, just in place where it is needed. This concerns not only text strings but other constant numeric values, too.
In my assembler I adopted syntax established by IBM in their assembler for mainframe computers (equal sign followed with data definition):

Option 4
========
MOV EBX, =B"Operation started."
MOV ESI, =B"Operation finished. Number of errors: "

More details at https://euroassembler.eu/eadoc/#Literals
some more examples: https://euroassembler.eu/eatests/t1711.htm

Bye,
vitsoft

[Alex McDonald]

On Friday, December 21, 2018 at 8:51:19 PM UTC+1, James Harris

So I wondered what other people do to incorporate strings in code.
What have you found to be the most readable and easiest to work
with?

I believe that the most convenient way is not having to invent a
unique symbol name for each string, but use the string value itself,
just in place where it is needed. This concerns not only text strings
but other constant numeric values, too. In my assembler I adopted
syntax established by IBM in their assembler for mainframe computers

That is considered "Bad Practice" for messages. It makes translating
code for other languages hard.

Because all the string & other = type constants have to be addressable,
it normally needs the CSECT in which they were referenced to have an
appropriate and addressable LTORG section. That means that several 4Ks
worth of messages might need several registers to be addressable, since
a single register can only address 4K at a time.

See
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.asma400/ltorg.htm.


It does have some advantages; two identical strings are only stored once
and so on. But overall, for large numbers of strings, it's not a
particularly good solution. One way of doing it is to give your messages
some kind of meaningful ID; for instance LNK001W, LNK002E, LNK003C for a
warning/error/critical message from a linker; and put the same text in
the message "LNK001W: invalid parameter %p ignored".

[R.Wieser]

Alex,

Because all the string & other = type constants have to be addressable, it
normally needs the CSECT in which they were referenced to have an
appropriate and addressable LTORG section.

He wrote he adopted the syntax. He never said he implemented it the same
way.

That is considered "Bad Practice" for messages. It makes translating code
for other languages hard.

:-) That did not stop IBM from creating their own specific solution to the
problem, now did it ?

Regards,
Rudy Wieser

[Rod Pemberton]

On Sun, 30 Dec 2018 20:53:26 +0100

Alex,

Post by Alex McDonald
Because all the string & other = type constants have to be
addressable, it normally needs the CSECT in which they were
referenced to have an appropriate and addressable LTORG section.

He wrote he adopted the [IBM] syntax. He never said he implemented
it the same way.

Yeah, I too was unsure how the conversation logic jumped from string
representations for x86 assembler to the best coding practices for IBM
mainframes and/or assembly software maintenance and portability. So, I
think the issue of relevance comes to mind, at least, to my mind.

Do IBM mainframes even use x86 processors? Are IBMs on-topic here?


Rod Pemberton

[Alex McDonald]

Post by R.Wieser
Alex,

Because all the string & other = type constants have to be addressable, it
normally needs the CSECT in which they were referenced to have an
appropriate and addressable LTORG section.

He wrote he adopted the syntax. He never said he implemented it the same
way.

Yes, I understand that. It is a very neat idea. I was pointing out the
limitations in the original implementation. It wasn't relevant here, I
agree.

Post by R.Wieser

That is considered "Bad Practice" for messages. It makes translating code
for other languages hard.

:-) That did not stop IBM from creating their own specific solution to the
problem, now did it ?

No, it didn't, but there are many features in many languages &
assemblers that are there for considered use and when appropriate; and I
don't think the use proposed is considered or appropriate. I still

Post by R.Wieser
I believe that the most convenient way is not having to invent a
unique symbol name for each string, but use the string value itself,
just in place where it is needed.

not to be good advice. YMMV etc.

[R.Wieser]

Alex,

and I don't think the use proposed is considered or appropriate

Personally I think its *very* apropriate. Doing away with scores of
unwanted, one-off text labels.

Similiar to the special "jump {x}unnamed labels forward/backward"
pseudo-labels. Which where a godsend when the relative jumps still only
had a range of +/- 128 bytes. You know, conditional jumps over a long(er)
jump, or even for short loops.

So yes, our mileages seem to vary. :-)

Regards,
Rudy Wieser

[Alex McDonald]

Post by R.Wieser
Alex,

and I don't think the use proposed is considered or appropriate

Personally I think its *very* apropriate. Doing away with scores of
unwanted, one-off text labels.

With all the messages buried in the source stream, managing them becomes
difficult at scale or if multiple target languages are to be supported.

Post by R.Wieser
Similiar to the special "jump {x}unnamed labels forward/backward"
pseudo-labels. Which where a godsend when the relative jumps still only
had a range of +/- 128 bytes. You know, conditional jumps over a long(er)
jump, or even for short loops.
So yes, our mileages seem to vary. :-)

Labels aren't text messages. There are several use cases for the =X
operand here. Hypothetically

label: mov eax, =c"message text"
mov ebx, =a(label)

The first is only appropriate for a very small source program or for
strings that don't require much management. The second (the A operator
is an address) is appropriate regardless of scale; labels don't in
general need any management.

[R.Wieser]

Alex,

Post by Alex McDonald
With all the messages buried in the source stream, managing them becomes
difficult at scale or if multiple target languages are to be supported.

If an assembler can manage labels just fine over multiple sourcefiles,
multiple non-overlapping segments and for structures and even can ceep track
changes in emitted code because of opcode changes depending on the distance
to the target label than I have no doubt that something simple as keeping
track of a few "at use" declared static(!) strings will not be much of a
problem either.

Post by Alex McDonald
Labels aren't text messages. There are several use cases for the =X
operand here.

You're again jumping to a fully other language / environment and how it
work(s|ed) there. Try to stay here, and with what the OP asked for.

Post by Alex McDonald
labels don't in general need any management.

As shown in the above, I think differently. In *general* they need quite a
bit. Only in fringe cases they need none.

Regards,
Rudy Wieser

[Alex McDonald]

Post by R.Wieser
Alex,

Post by Alex McDonald
With all the messages buried in the source stream, managing them becomes
difficult at scale or if multiple target languages are to be supported.

If an assembler can manage labels just fine over multiple sourcefiles,
multiple non-overlapping segments and for structures and even can ceep track
changes in emitted code because of opcode changes depending on the distance
to the target label than I have no doubt that something simple as keeping
track of a few "at use" declared static(!) strings will not be much of a
problem either.

Perhaps I didn't make myself clear. The problem is the programmer's, not
the assembler's. The languages I mean are human ones.

Post by R.Wieser

Post by Alex McDonald
Labels aren't text messages. There are several use cases for the =X
operand here.

You're again jumping to a fully other language / environment and how it
work(s|ed) there. Try to stay here, and with what the OP asked for.

You'll need to be clearer here. I'm not understanding how discussing the
the OP's assembler and its literal string =B feature is "jumping to a
fully other language".

Post by R.Wieser

Post by Alex McDonald
labels don't in general need any management.

As shown in the above, I think differently. In *general* they need quite a
bit. Only in fringe cases they need none.

Generally I wouldn't expect to translate the labels from something to
English or Spanish or German or French when internationalising an app. I
would do that for the static text in the app.

Which is where we came in. Used sparingly, =B strings are fine. I
wouldn't use beyond a handful because it's more difficult to manage
inlined messages at scale.

[R.Wieser]

Alex,

Post by Alex McDonald
Perhaps I didn't make myself clear. The problem is the programmer's,
not the assembler's. The languages I mean are human ones.

Than your statement is stil nonsense. We *all* program in the same
programming language, regardless of what the persons mothertongue is (fringe
cases like stupid MS decisions excluded).

Post by Alex McDonald
You'll need to be clearer here. I'm not understanding how discussing the
the OP's assembler and its literal string =B feature is "jumping to a
fully other language".

The problem is that you, at times, are *not* discussing the OPs choices or
assembler (1) - but instead are talking about choices that are made by IBM
or solutions other people created for themselves - while making it sound as
if they are facts taken from the OP.

(1) How can you, as he has not mentioned his assembler. Nor has he posted
anything about his final choice or how he has, or intended to, implemented
it.

As for the "jumping to a fully other language" ? Besides sthe "I was
pointing out the limitations in the original implementation" you mean ?
What about your "Labels aren't text messages. There are several use cases
for the =X operand here." - where you fully ignored the OPs intended usage
and went for ... well, something else. IBMs interpretation perhaps ?
The "euroassembler" one ? Who knows, you never mentioned it.

Post by Alex McDonald
Generally I wouldn't expect to translate the labels from something to
English or Spanish or German or French when internationalising an app.

Whut ? And what was that "The languages I mean are human ones" than all
about ? You're not making much sense here you know. :-(

Post by Alex McDonald
Which is where we came in. Used sparingly, =B strings are fine.

And used every second line or even more often than that it will, on a
technically level, work fine too.

Post by Alex McDonald
I wouldn't use beyond a handful because it's more difficult to manage
inlined messages at scale.

For whom ? Not the assembler - something I already tried to make clear
and I have not seen you respond to in any way (1). Not by shooting holes in
what I said, nor by coming up with your own underbuilding to why it would be
so - , and that leaves you. *Your* personal stance is that *you* cannot
handle it. But how is that relevant to the OP ? You're right, it isn't.

(1) but that obviously doesn't stop you from claiming the same again.
Rather bad form dude. :-(

Regards,
Rudy Wieser

[Rod Pemberton]

On Mon, 31 Dec 2018 17:29:54 +0000

Post by Alex McDonald

Post by R.Wieser

Post by Alex McDonald
Labels aren't text messages. There are several use cases for the =X
operand here.

You're again jumping to a fully other language / environment and
how it work(s|ed) there. Try to stay here, and with what the OP
asked for.

You'll need to be clearer here. I'm not understanding how discussing
the the OP's assembler and its literal string =B feature is "jumping
to a fully other language".

Your newsreader sucks (or has too much filtering) ...

James Harris was the OP. Pavel Srubar replied to him.
Pavel introduced the =B feature into the conversation.


Rod Pemberton

[R.Wieser]

Alex,

Post by Alex McDonald
With all the messages buried in the source stream, managing them becomes
difficult at scale or if multiple target languages are to be supported.

Last night I came to the realization that you where most likely talking
about a program which would display messages in the language the user has
selected as his preference.

In that case, what is than the problem for the programmer to decide *not* to
use in-line strings for those ?

... even though using the standard "by label reference" doesn't solve
anything in that regard.

In other words, why have you tried to point out a problem that should be
solved by (an implementation of) literal strings when its not at all limited
to just them ?

Also, why *at all* try to wrangle a literal string implementation into
something a regular label already does ( "=a(label)" ) ? That doesn't make
much, if any, sense.


And although there are multiple solutions available involving the standard
"by label reference" method, *none* of them are easy to manage if you do not
want to have to reassemble the whole source when you have only replaced the
language strings (read: have placed them in their own file).

Though if you do not care about having to reassemble the whole program
(creating seperate executables, one for each targetted language) than a bit
of pre-processor magic on the literal strings will ofcourse solve the
multi-language problem just fine. <whoops!>

Regards,
Rudy Wieser

[Rick C. Hodgin]

Post by James Harris
What's the most readable way to include string literals in asm source code?

In assembly, it's important to have readability for maintenance, but you
often use assembly code for a reason.

If you intermix data and code you'll be polluting the instruction cache
with unnecessary data that's not needed.

Post by James Harris
Of course, code layout is not a major issue but it is one of convenience; and
readability is important. So I wondered what other people do to incorporate
strings in code. What have you found to be the most readable and easiest to
work with?

My advice is if you need true readability, create a tool that will
allow you to write source code in a nice format, and then translate
your source code to a form that is conducive to the needs of the CPU
you're writing code for.

Make it look the way you'd like to see it, but then have the tool
translate it to the needs of the machine.

[R.Wieser]

Rick,

Post by Rick C. Hodgin
If you intermix data and code you'll be polluting the instruction cache
with unnecessary data that's not needed.

You're jumping to conclusions.

The idea is that the programmer can define the strings where they are used.
But there is nothing stopping the implementation from gathering and putting
them into a data segment (either per procedure, or even globally).

Pretty-much the same way how a programmer can define data segments that are
in the scope of a procedure (allowing local data labels), but in the end
they all get stuffed into a single, big one (witch no slack space/filler
bytes in between).

Post by Rick C. Hodgin
Make it look the way you'd like to see it, but then have the tool
translate it to the needs of the machine.

And that seems to be exactly his goal. With the "tool" being whatever his
assembler already has in regard to a preprocessor and/or macro language.

Regards,
Rudy Wieser

[Alex McDonald]

Post by Rick C. Hodgin

Post by James Harris
What's the most readable way to include string literals in asm source code?

In assembly, it's important to have readability for maintenance, but you
often use assembly code for a reason.
If you intermix data and code you'll be polluting the instruction cache
with unnecessary data that's not needed.

How so? The literals are assembled out of line of the code.

Post by Rick C. Hodgin

Post by James Harris
Of course, code layout is not a major issue but it is one of
convenience; and readability is important. So I wondered what other
people do to incorporate strings in code. What have you found to be
the most readable and easiest to work with?

My advice is if you need true readability, create a tool that will
allow you to write source code in a nice format, and then translate
your source code to a form that is conducive to the needs of the CPU
you're writing code for.
Make it look the way you'd like to see it, but then have the tool
translate it to the needs of the machine.

In other words, use an assembler or compiler with good programmer
facilities. Preprocessors are a nuisance, especially macro driven beasts
like m4. The idea is to simplify, the outcome is complexity.

[R.Wieser]

Alex,

Post by Alex McDonald
How so? The literals are assembled out of line of the code.

Again, you have zero knowledge about how the OP implemented it (or is
thinking about doing it). You should therefore not be throwing absolutes
like that around.

But you're still stuck on that IBM of yours aren't you ? Even though this
newsgroup is about x86 processors, which, if I may take your "a single
register can only address 4K at a time", isn't what what IBM uses(s|d) for
its mainframes.

Post by Alex McDonald
In other words, use an assembler or compiler with good programmer
facilities.

Without any kind of explanation to what "good programmer facilities" are
that statement is rather meaningless I'm afraid.

Post by Alex McDonald
Preprocessors are a nuisance, especially macro driven beasts like m4.

Everything can be done overdone, or even done badly. Thats not a reason to
exclude all usage of it. If it where than all kinds of activities would be
forbidden. Ranging from driving vehicles, kicking a leather air-filled sack
around, eating and even drinking of pretty-much everything (including
water), as well as politics and religion (of any kind).

And now I think of it, especially programming. Both overdone as well as
done badly. :-)

Post by Alex McDonald
The idea is to simplify, the outcome is complexity.

Quite so. And sometimes that includes having done something "complex" done
by a preprocessor,a macro language and/or something build into the assembler
itself so the programmers task becomes easier (and less repetetive).

For example, my assembler allows me to set up a procedure which allows for
the definition of arguments (automatically converted to [bp+...] when
assembling), local labels - for stack and data segment alike - , used
register and memory locations (automaticaly POPed on when a RET is
encountered - which also automatically gets told how many argument bytes to
skip). It also allows me a call the function with all of the needed
arguments on the same line.

It also allows me to call such a procedure, with the arguments for it on the
same line as the call. Very handly, as I do not even need to think about
how many arguments, or even in which order they need to be pushed.

You see, a "procdesc" allows me to strictly define the calling type
(influencing the order in which the arguments are pushed), the ammount
ammount and type of arguments for the specified procedure, which the
assembler than checks against any call I make to it.

*None* of that is in *any* way related to a puristic view of what an
assembler is there for (the conversion from mnemonics to machinecode).

Regards,
Rudy Wieser

[Alex McDonald]

Post by R.Wieser
Alex,

How so? The literals are assembled out of line of the code. >

Again, you have zero knowledge about how the OP implemented it (or is
thinking about doing it). You should therefore not be throwing absolutes
like that around.

Perhaps I read the doc, and you didn't. The literals are assembled out
of line of the code. https://euroassembler.eu/eadoc/#Literals

Post by R.Wieser
But you're still stuck on that IBM of yours aren't you ? Even though this
newsgroup is about x86 processors, which, if I may take your "a single
register can only address 4K at a time", isn't what what IBM uses(s|d) for
its mainframes.

That I addressed in my previous post when I said "It wasn't relevant
here, I agree." Perhaps you didn't read that either.

[snip]

[R.Wieser]

Alex,

Post by Alex McDonald
Perhaps I read the doc

Possibly. Did you ?

But it certainly isn't any doc the OP (nor rick) referred to or even made
possible for you to find.

You've simply grabbed something "pavel" posted about how he solved it for
*his* assembler and you're now trying to use that, unquoted and not referred
to either, as an "this is how it is" argument towards Rick. Again, with
zero consideration for the OPs implementation (if any).

What the f*ck are you trying to pull here ?

Post by Alex McDonald
That I addressed in my previous post when I said "It wasn't relevant here,
I agree."

But that sure did not stop you from doing it again, now did it ?

Post by Alex McDonald
Perhaps you didn't read that either.

I read it. And I *thought* you would have learned from it. My mistake.

Regards,
Rudy Wieser

[Rick C. Hodgin]

Post by Alex McDonald

Post by Rick C. Hodgin
My advice is if you need true readability, create a tool that will
allow you to write source code in a nice format, and then translate
your source code to a form that is conducive to the needs of the CPU
you're writing code for.
Make it look the way you'd like to see it, but then have the tool
translate it to the needs of the machine.

In other words, use an assembler or compiler with good programmer
facilities...

Sort of. I assume if the tools he has work adequately to his needs
or tastes he wouldn't be askimg the question.

I assume a different, custom desire, one which requires a type of
compiler that takes the syntax he desires, and translates it to
the needs of the assembler.