From: Peter Flass on
Georg Bauhaus wrote:
> On 6/8/10 8:27 AM, James J. Weinkam wrote:
>> Nevertheless, it remains true that the assembly language programmer who
>> knows what he is about has complete control over the binary code
>> generated, although I would venture to say that few, if any, assembly
>> language programmers think of what they are doing in those terms most of
>> the time.
> Would this control include control over pipelines, parallelism,
> and possibly translation of assembly instructions to microcode?

Probably more so than with a(n) HLL. For example, if you're concerned
about it, you can organize instructions to maximize parallelism.
From: robin on
"Shmuel (Seymour J.) Metz" <spamtrap(a)> wrote in message
| In <4c0bbadb$0$34203$c30e37c6(a)>, on 06/07/2010
| at 01:12 AM, David Frank <robin51(a)> said:
| >What don't you understand about the publication,
| >"Automatic Digital Computation"?
| Its relevance.

It has the documented evidence of numerical programs

| >With that information, most people can find the publication and read
| >it.
| So can you. The last time that I went through that exercise, it turned
| out that you had lied.

I don't lie. If anyone is lying it's you. You haven't povided
any documentary evidence to back up your silly claims.

From: robin on
"Peter Flass" <Peter_Flass(a)> wrote in message news:hujp34$m4p$1(a)

| That's it. I believe it was an IBM 704, although probably other old
| computers used them also. Drums were popular as storage on systems,
| even with disks, because, being head per track, they were much faster.
| They were often used as a swap medium.

Some drums were head-per-track.
Those on the Pilot ACE (and ACE too, I think) and DEUCE had moving
heads for their drums.

From: glen herrmannsfeldt on
In comp.lang.fortran James J. Weinkam <jjw(a)> wrote:

> Your point is well taken for machines of the 60's and 70's,
> at least for the IBM ones with which I am most familiar.
> For example in 360 assembler, if you wanted to add two numbers
> you had your choice of A, AR, AH, AP, AL, ALR, AE, AER, AD,
> ADR, AXR, AU, AUR, AW, AWR and maybe a few more that I have
> forgotten. There was a one-to-one correspondence between each
> of these mnemonics and their corresponding numerical op codes.
> The assembly language programmer had to choose the correct
> mnemonic instruction to suit the circumstances.


And note that the hex value for the opcode for many of those
add instructions has A for its low digit. Also, the divide
instructions have D for their low hex digit. Subtract
and multiply come in between, with B and C.

Starting with S/370, some instructions have a two byte opcode.

There are now even more add instructions with 64 bit operations
in z/Architecture, AGR, AGFR, AY, AG, AGF, add logical with
carry ALCR, ALCGR, ALC, ALCG, IEEE binary floating point
operations AEBR, ADBR, and AXBR, and finally decimal floating
point instructions ADTR and AXTR.

-- glen
From: Peter Hermann on
In comp.lang.ada J. Clarke <jclarke.usenet(a)> wrote:
> working with assembler but in my day it was a 1:1 correspondence--you
> knew exactly what binary each assembly language instruction would emit,

in the zenith of Assembler (-: i.e. after your time :-)
we had macros which could produce hundreds of
statements with one stroke...