comp.lang.asm.x86 Google Group

Re: Debugger for AMD64?

t...@is.invalid (David) — Tue, 05 Jan 2010 14:46:52 UT

Windows .. there is CDB as well - but I just want to open the debugger, type
"a", do my own thing, hit "t" a couple to see the results.
I'll search for that.

Re: Debugger for AMD64?

alexfrun...@munged.microcosmotalk.com (Alexei A. Frounze) — Tue, 05 Jan 2010 08:10:04 UT

On Jan 4, 2:25 pm, "BGB / cr88192" <cr88...@MUNGED.microcosmotalk .com>
wrote:
Other Microsoft debuggers (console) are:
NTSD, CDB and KD.
NTSD is in \windows\system32 on WinXP.
See more here: [link]
Alex

Re: Debugger for AMD64?

fbkot...@munged.microcosmotalk.com (Frank Kotler) — Mon, 04 Jan 2010 22:49:21 UT

Sztacheta - jozeksztacheta wrote... but the clax86 moderation software
ate his post (for some reason)
Try FDBG
[link]
Sorry to have dropped your post - hope I've got it right! Thanks!
Best,
Frank

Re: Debugger for AMD64?

cr88...@munged.microcosmotalk.com (BGB / cr88192) — Mon, 04 Jan 2010 22:25:16 UT

for which OS?...
if Windows, I am using WinDbg, but granted this is not a command-line
debugger.
still has support for disassembly, ...
for Linux, there is GDB...
I think there may be a Win64 port of GDB by now, but I have not checked.
I forget where exactly, but I think there was also a command-line debugger

Debugger for AMD64?

t...@is.invalid (David) — Mon, 04 Jan 2010 20:10:27 UT

Anyone know of a AMD64 compatible symdeb/debug (command line) type debugger?
I use them all the time to test instruction results. For i386 I use ddeb,
but don't know of an AMD64 version?

Re: Calling convention odd?

n...@munged.microcosmotalk.com (Richard Russell) — Mon, 04 Jan 2010 11:18:38 UT

I'm not even sure you can say "commercially obsolete". The ARM is the
highest-volume 32-bit (or more) processor in the world by a very large
margin, with approximately 1,500,000,000 per year being shipped
currently (yes, that's one-and-a-half billion!), mostly going into
cellphones.
Richard.
[link]

Re: Calling convention odd?

do_not_h...@nohavenot.cmm (Rod Pemberton) — Mon, 04 Jan 2010 11:17:55 UT

RISC
per
It is accurate.
True too, but that wasn't my point.
"per CPU clock" too was my point.
If one averages CISC work per instruction to a per clock basis so that they
can be compared with RISC, CISC instructions do more work per clock than
RISC. That was part of the reason why RISC failed. The conjecture that

Re: Calling convention odd?

do_not_h...@nohavenot.cmm (Rod Pemberton) — Mon, 04 Jan 2010 11:17:32 UT

Bad, why?
By use of the word "This", below, I mean combination unrelated operations
into a single operation.
1) This is a key technique they use to speed up interpreters. It's called
"super instructions" (Anton Ertl) or "superoperators" (Todd Proebstring).
2) This is also a key technique used in recent x86 processors. It's called

Re: Calling convention odd?

nowh...@never.at (wolfgang kern) — Mon, 04 Jan 2010 11:17:21 UT

"Tim Roberts" asked:
I just looked at the CPU-internal Register-numbers, and as the first three
might also be the most used/altered/instruction-inher ent since 8000, this
could be the reason for not saving their contents in Lib-functions of HLLs.
__
wolfgang

Re: Calling convention odd?

fbkot...@munged.microcosmotalk.com (Frank Kotler) — Mon, 04 Jan 2010 11:17:12 UT

The fact that the "callee preserves" registers are the same ones that
can be used in an effective address (16-bit) may be relevant... or not...
Best,
Frank

Re: Calling convention odd?

t...@munged.microcosmotalk.com (Tim Roberts) — Mon, 04 Jan 2010 02:34:22 UT

Although I agree with your naming, this seems like a non sequitur. Why do
you think this supports the choice of volatile registers in the calling
convention?

Re: Calling convention odd?

t...@munged.microcosmotalk.com (Tim Roberts) — Mon, 04 Jan 2010 02:33:44 UT

That's not accurate. You can say "they do less work per instruction"
compared to CISC, but not "per CPU clock". The typical RISC set runs one
instruction per clock, and it's difficult to do much better than that.
Most x86 compilers use the CPUs as if they were RISC anyway, by eschewing
the more complicated instructions. Look at the CPU code generated by an

comp.lang.asm.x86 FAQ

jcarl...@munged.microcosmotalk.com (Jim Carlock) — Sat, 02 Jan 2010 23:01:31 UT

Before posting technical questions please read the FAQ:
[link]
You may also download a copy in zip format from the above site.
The original version (which has not been updated since 21 March 2000)
can still be accessed from:
[link]

Re: NOTICE: C.L.A.X service interruption!

red...@ev1.net.invalid (Robert Redelmeier) — Sat, 02 Jan 2010 05:48:42 UT

Jim Carlock <jcarl...@munged.microcosmotal k.com> wrote in part:
ssh is the std in the Unix world, you could look at
[link] or
[link]
for host [server] software.
These should give you a fully encrypted channel, with public keys
used to exchange a session [private] key _before_ you login with

Re: multithreading in Asm

cr88...@munged.microcosmotalk.com (BGB / cr88192) — Sat, 02 Jan 2010 01:59:48 UT

this is more true of processes than of threads...
the OS handles threads, but is not necessary to use it to have threads...
more so, in the case of many HLL's, it is not even really necessary that
there be multiple OS threads to implement multiple HLL threads. this could
be the case either with an interpreter (which could jump between interpreter