News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

My first post: Array of Strings in Assembly.

Started by AssemblyChallenge, August 20, 2014, 07:24:56 AM

Previous topic - Next topic

dedndave

if you have strings of different lengths, use a vector table

apTable dd szString1,szString2,szString3

szString1 db "cdfsfsdfsdfs",0
szString2 db "52353453453453",0
szString3 db "234j4kjokijkl",0


the index into the table is always a multiple of 4   :biggrin:

jj2007

Sometimes it's good to have the length of the strings, too:
include \masm32\include\masm32rt.inc

.code
apTable dd sizeof szString1, szString1, sizeof szString2, szString2, sizeof szString3, szString3

szString1 db "cdfsfsdf",0
szString2 db "52353453453453 lonoooooong",0
szString3 db "234j4kjokijkl",0

start: mov esi, offset apTable
xor ebx, ebx
.Repeat
print str$([esi+8*ebx]), " bytes: ", 9
print [esi+8*ebx+4], 13, 10
inc ebx
.Until ebx>2
exit
end start

Zen

ASSEMBLYCHALLENGE,
When I started out in assembly programming, I bought the Fifth Edition of Kip Irvine's, ''Assembly Language for x86 Processors". I found a copy in the University of California's library,...it's really the only thing out there for novice assembly programmers. But, it has problems. We get posts all the time here at the MASM Forum from beginners who are trying to use Irvine's Library procedures with procedures from the MASM package. As you will notice after you've read a number of the examples from the MASM package, Irvine's procedures will not work with the example code provided in the MASM examples directory. Irvine's code is extremely simplistic, and is designed to work only with other Irvine routines. I suggest you read through some of the example code in the MASM package,...it's much better written, demonstrates actual techniques that you would use in a real program, and, in general, works well with any procedures that you may write yourself.   
Also, a large portion of the book is devoted to 16-bit DOS programming, including an explanation of using interrupts in your executable. Both of these techniques are no longer useful. Current versions of the Windows Operating System will NOT execute 16-bit DOS code (except using an emulator), and calling either hardware or software interrupts in a MASM program will crash your application.
Also,...and this is important,...he provides hardly any useful information at all about floating point techniques. The documentation provided by Intel is especially useful in this regard. You probably already know about this, but, here is the website for downloading: IntelĀ® 64 and IA-32 Architectures Software Developer Manuals. They are definitely the most useful documentation on assembly programming available on this planet,...
Volume 1, Basic Architecture, IA 32 Software Developer's Manual, Chapter Eight, PROGRAMMING WITH THE X87 FPU.

dedndave

#18
you can search the forum for mention of Kip
the biggest issue is that kips  library does not follow the rules of the windows ABI

jj2007

Zen & Dave,

Kip's lib is not really the latest state-of-the-art, but it can be used flawlessly with Masm32 and even MasmBasic. There is a demo in \Masm32\MasmBasic\IrvineMb\IrvineMasm32.asc - open in \Masm32\MasmBasic\RichMasm.exe and hit F6.

As to the ABI thing: There is really no urgent need to start another holy war on this, but as a matter of fact, Kip preserves more regs than needed, and is therefore on the safe side. Coders need to pay attention that Win32 API calls trash ecx and edx, but that doesn't mean that saving them is dangerous.

dedndave

#20
quite often, arguments are passed in EBX, ESI, or EDI (usually EDI, i think) - that's not per the ABI

kip irvine floating point routines are buggish

also.....

1) In the kip irvine library, the "OPTION CaseMap:None" directive is commented out as optional.
   Per Microsoft API documentation, case sensitivity should be observed.
   The Masm32 library is also designed for case sensitive symbols.

2) The POINT structure is defined with members named upper-case "X" and "Y".
   Per Microsoft documentation, these are named lower-case "x" and "y".

3) "GetTextColor" and "SetTextColor" are functions defined in the kip irvine library.
   They are used to retrieve and set console-mode text color.
   However, pre-existing Microsoft API functions (used for GUI apps) are defined in Gdi32.dll.

4) "MsgBox" is a PROC defined in kip irvine, used in a few kip irvine example programs.
   "MsgBox" is a powerful MACRO defined in Masm32, used in many existing programs.

5) "exit" is a TEXTEQUate (pseudo-macro) defined in kip irvine library.
   "exit" is a MACRO defined in Masm32 that allows an optional return code argument.
   The Masm32 macro will perform the same function if no arguments are specified.

6) The kip irvine prototype for SetConsoleCursorPosition uses a COORD type.
   While this is technically correct, the Masm32 library uses a more desirable DWORD type.

Gunther

Quote from: jj2007 on August 21, 2014, 04:18:41 AM
As to the ABI thing: There is really no urgent need to start another holy war on this, but as a matter of fact, Kip preserves more regs than needed, and is therefore on the safe side. Coders need to pay attention that Win32 API calls trash ecx and edx, but that doesn't mean that saving them is dangerous.

It's not false to save ECX and EDX during a CALL, but following the calling conventions that's not necessary. But all that depends on the circumstances and the selected CALL (STDCALL, FASTCALL etc). Saving all registers reduces side effects, but is not the fastest way. If someone wants to program defensive, the register save method is right.

Gunther
You have to know the facts before you can distort them.

hutch--

> Coders need to pay attention that Win32 API calls trash ecx and edx

This is simply the Intel ABI that Microsoft support. You preserve them if you need to at the caller end, not in the called proc. We all know how to write code that is not interacting with the OS to use all 8 registers (Copy ESP into a DWORD variable and copy it back later) but it must be done AFTER the correct registers are preserved lower down the call tree. If you don't it will go BANG somewhere.

Its not a holy war, its a voice crying in the wilderness, stop misleading learners so they write dangerous unreliable code and give up assembler after it keeps crashing. Once they know how it all works, they can develop bad habits like the rest of us.  :biggrin:

nidud

#23
deleted

jj2007

#24
Quote from: hutch-- on August 21, 2014, 05:31:59 AM...it must be done AFTER the correct registers are preserved lower down the call tree. If you don't it will go BANG somewhere.

OMG, Hutch, can you now kindly quote the phrase where I wrote that "the correct registers" should NOT be preserved???

If my intention was to "mislead learners" and make them addicted to HIGH RISK CODING, then I would write "use esi edi ebx as you like, especially in callbacks". But I didn't write that; what I wrote instead is "YES YOU ARE F**CKING ALLOWED TO SAVE AN EXTRA REGISTER LIKE ECX BECAUSE THIS IS A FREE WORLD, AND TRUST ME, IF YOU SURROUND YOUR CODE WITH PUSH ECX ... POP ECX, IT WILL NEVER EVER CRASH, AMEN".

JJ (weeping in the wilderness)


@Dave: nice list of issues, it seems you studied Kip's library throughly :t

hutch--

I think you have missed the drift of my comments, for the last 15 years or so I have been fighting a losing battle to get folks learning assembler to comprehend the ABI so that their code works on all versions of Win32 yet year after year I get people who want to modify the ABI with the comments that it does not really matter or it works on Win?? in their language version and year after year I see learners write dangerous code that crashes because they have not protected the required registers.

The subtleties get lost in the noise and many learners fall by the wayside because they have to digest so much that they cannot differentiate between useful and obscure or at times ever wrong information. The old fellas all know how to write irregular code somewhere up a call tree that uses all 8 registers and any mix you like of MMX and even SSE registers but it does not help the learner to try and follow the obscurities when they have yet to learn the basics.

I posted a very simple example to show the original poster that protecting the required registers produces safe code rather than the Irvine technique that does not. As usual the effort was wasted because it was lost in the noise.

Oliver Scantleberry

Why do you keep typing the letters "xD xD" for? Is it supposed to mean something?

Oliver Scantleberry

Quote from: jj2007 on August 20, 2014, 04:15:49 PM
Quote from: hutch-- on August 20, 2014, 03:46:39 PM
The spec allows you to trash EAX ECX and EDX

But the ABI does not force you to trash these regs. For example, if a coder for whatever strange reasons thinks that ecx is a precious register that should be preserved between calls to a library, as demonstrated here, then he is absolutely free to do so. No (legit) sheriffs will show up and throw you in the coder's jail 8)

"But the ABI does not Force you to trash these regs." You may be interested to know that the ABI doesn't force you to eat the tires off UPS trucks either.

jj2007

Quote from: Oliver Scantleberry on April 08, 2016, 02:14:27 PMthe ABI doesn't force you to eat the tires off UPS trucks either.

Quote from: Oliver Scantleberry on April 08, 2016, 12:54:27 PM
I thought UPS delivered packages. Now they do power glitches too?

At your age, I'd be really careful with these mushrooms 8)

Oliver Scantleberry