Prev: Request for parallel computing books in comp.parallel
Next: Press Release - Reliable Software Technologies, Ada-Europe 2010
From: Peter Flass on 8 Jun 2010 06:43
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 8 Jun 2010 07:10
"Shmuel (Seymour J.) Metz" <spamtrap(a)library.lspace.org.invalid> wrote in message
| In <4c0bbadb$0$34203$c30e37c6(a)exi-reader.telstra.net>, on 06/07/2010
| at 01:12 AM, David Frank <robin51(a)dodo.com.au> said:
| >What don't you understand about the publication,
| >"Automatic Digital Computation"?
| Its relevance.
It has the documented evidence of numerical programs
performed BEFORE FORTRAN and ALGOL.
| >With that information, most people can find the publication and read
| 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 8 Jun 2010 07:16
"Peter Flass" <Peter_Flass(a)Yahoo.com> wrote in message news:hujp34$m4p$1(a)news.eternal-september.org...
| 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 8 Jun 2010 08:03
In comp.lang.fortran James J. Weinkam <jjw(a)cs.sfu.ca> 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.
From: Peter Hermann on 8 Jun 2010 08:26
In comp.lang.ada J. Clarke <jclarke.usenet(a)cox.net> 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...