Groups > alt.folklore.computers > #161395 > unrolled thread

Which Books Can You Recommend For Learning Computer Programming?

Started by	Neo Fortune <serenity3043@gmail.com>
First post	2016-03-23 02:31 -0700
Last post	2016-03-30 14:56 +0100
Articles	20 on this page of 401 — 44 participants

Back to article view | Back to alt.folklore.computers

Page 20 of 21 — ← Prev page 1 … 18 19 [20] 21 Next page →

#161755

From	Peter Flass <peter_flass@yahoo.com>
Date	2016-03-31 16:36 -0400
Message-ID	<521616349.481149072.705955.peter_flass-yahoo.com@news.eternal-september.org>
In reply to	#161747

Charles Richmond <numerist@aquaporin4.com> wrote:
> "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote in message 
> news:ndjfg10kf5@news3.newsguy.com...
>> 
>> [snip...]                         [snip...] 
>> [snip...]
>> 
>> But for demonstrating machine code, how about the good old IBM 360?
>> One byte for opcode, one for registers or length(s), followed by zero,
>> one, or two 2-byte address specifications.  Neat and tidy, and once you
>> get your head around base/displacement it's quite straightforward.
>> After that, maybe a bit of PDP-11; I remember being dazzled by the
>> elegance that came from making PC and SP just two more registers.
>> 
> 
> The PDP-11 *did* make the PC and the SP just two more registers.  But later 
> so did the MC68000:  A6 was the stack pointer and A7 was the program 
> counter.  I do *not* know it, but I would guess that in the PDP-11, since R7 
> was the PC and R6 was the SP... in most C compilers, R5 would be used as the 
> frame pointer and R4 would be the globals pointer.  Just a guess...
> 
> The IBM 360 had some specialized instructions like ED and EDMK, or TR and 
> TRT that were minimally useful.  But I think the great shortcoming is the 
> lack of immediate instructions to load or do arithmatic with a constant. 
> The similar job was done using the Literal Pool, but it's just *not* the 
> same.  One always had to be mindful that the literal pool constants remain 
> addressable... that you had enough base registers to extend the area.
> 

Immediate fixed now in System/z.  I would say that the instructions you
mention were more than "minimally useful."  ED and EDMK were used any time
the programmer wanted to format some output.  A subroutine to perform the
same functions would be fairly lengthy.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#161778

From	scott@slp53.sl.home (Scott Lurndal)
Date	2016-04-01 13:04 +0000
Message-ID	<XluLy.87496$111.24610@fx31.iad>
In reply to	#161755

Peter Flass <peter_flass@yahoo.com> writes:
>Charles Richmond <numerist@aquaporin4.com> wrote:
>> "Charlie Gibbs" <cgibbs@kltpzyxm.invalid> wrote in message 
>> news:ndjfg10kf5@news3.newsguy.com...
>>> 
>>> [snip...]                         [snip...] 
>>> [snip...]
>>> 
>>> But for demonstrating machine code, how about the good old IBM 360?
>>> One byte for opcode, one for registers or length(s), followed by zero,
>>> one, or two 2-byte address specifications.  Neat and tidy, and once you
>>> get your head around base/displacement it's quite straightforward.
>>> After that, maybe a bit of PDP-11; I remember being dazzled by the
>>> elegance that came from making PC and SP just two more registers.
>>> 
>> 
>> The PDP-11 *did* make the PC and the SP just two more registers.  But later 
>> so did the MC68000:  A6 was the stack pointer and A7 was the program 
>> counter.  I do *not* know it, but I would guess that in the PDP-11, since R7 
>> was the PC and R6 was the SP... in most C compilers, R5 would be used as the 
>> frame pointer and R4 would be the globals pointer.  Just a guess...
>> 
>> The IBM 360 had some specialized instructions like ED and EDMK, or TR and 
>> TRT that were minimally useful.  But I think the great shortcoming is the 
>> lack of immediate instructions to load or do arithmatic with a constant. 
>> The similar job was done using the Literal Pool, but it's just *not* the 
>> same.  One always had to be mindful that the literal pool constants remain 
>> addressable... that you had enough base registers to extend the area.
>> 
>
>Immediate fixed now in System/z.  I would say that the instructions you
>mention were more than "minimally useful."  ED and EDMK were used any time
>the programmer wanted to format some output.  A subroutine to perform the
>same functions would be fairly lengthy.

And most of your complaints about 80286 were fixed in 80386 and beyond.

As for ED/EDMK (or EDT in Burroughs mainframes), why include all that
in the hardware (with the associated area, verification and power
costs) when a well-tuned software version performs almost as well
and is much more flexible?

[toc] | [prev] | [next] | [standalone]

#161793

From	Charlie Gibbs <cgibbs@kltpzyxm.invalid>
Date	2016-04-01 19:11 +0000
Message-ID	<ndmh4401746@news4.newsguy.com>
In reply to	#161778

On 2016-04-01, Scott Lurndal <scott@slp53.sl.home> wrote:

> Peter Flass <peter_flass@yahoo.com> writes:
>
> And most of your complaints about 80286 were fixed in 80386 and beyond.

That's a relief to know.

> As for ED/EDMK (or EDT in Burroughs mainframes), why include all that
> in the hardware (with the associated area, verification and power
> costs) when a well-tuned software version performs almost as well
> and is much more flexible?

That may be true now, but back in the '60s and '70s CPU cycles were
a scarce commodity, and it was worthwhile to put things into hardware
like ED/EDMK (or CKD disks, for that matter).

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

[toc] | [prev] | [next] | [standalone]

#161836

From	hancock4@bbs.cpcn.com
Date	2016-04-02 13:06 -0700
Message-ID	<3e3b0585-0d6c-4a20-b1ef-3c7bbd6d8da7@googlegroups.com>
In reply to	#161778

On Friday, April 1, 2016 at 9:04:56 AM UTC-4, Scott Lurndal wrote:

> As for ED/EDMK (or EDT in Burroughs mainframes), why include all that
> in the hardware (with the associated area, verification and power
> costs) when a well-tuned software version performs almost as well
> and is much more flexible?

Why did IBM wait so long to add square-root as an assembler
command in the mainframe?  Even business applications use it.

[toc] | [prev] | [next] | [standalone]

#161854

From	Dan Espen <despen@verizon.net>
Date	2016-04-02 21:25 -0400
Message-ID	<ndpr87$e03$1@dont-email.me>
In reply to	#161836

hancock4@bbs.cpcn.com writes:

> On Friday, April 1, 2016 at 9:04:56 AM UTC-4, Scott Lurndal wrote:
>
>> As for ED/EDMK (or EDT in Burroughs mainframes), why include all that
>> in the hardware (with the associated area, verification and power
>> costs) when a well-tuned software version performs almost as well
>> and is much more flexible?
>
> Why did IBM wait so long to add square-root as an assembler
> command in the mainframe?  Even business applications use it.

They were waiting for me to see it needed somewhere.

Too late now.
They implemented the instruction before I needed it
and I'm not looking any more.

-- 
Dan Espen

[toc] | [prev] | [next] | [standalone]

#161888

From	Walter Bushell <proto@panix.com>
Date	2016-04-03 12:52 -0400
Message-ID	<proto-C1B3A8.12520603042016@news.panix.com>
In reply to	#161836

In article <3e3b0585-0d6c-4a20-b1ef-3c7bbd6d8da7@googlegroups.com>,
 hancock4@bbs.cpcn.com wrote:

> On Friday, April 1, 2016 at 9:04:56 AM UTC-4, Scott Lurndal wrote:
> 
> > As for ED/EDMK (or EDT in Burroughs mainframes), why include all that
> > in the hardware (with the associated area, verification and power
> > costs) when a well-tuned software version performs almost as well
> > and is much more flexible?
> 
> Why did IBM wait so long to add square-root as an assembler
> command in the mainframe?  Even business applications use it.

Fast to implement in software, if you have multiply and divide
ops.

-- 
 To terrify children with the image of hell,
 to consider women an inferior creation is that good for the world?  
  Christopher Hitchens

[toc] | [prev] | [next] | [standalone]

#161758

From	Bob Eager <news0006@eager.cx>
Date	2016-03-31 20:57 +0000
Message-ID	<dm5haiFflomU26@mid.individual.net>
In reply to	#161747

On Thu, 31 Mar 2016 14:45:16 -0500, Charles Richmond wrote:

> The PDP-11 *did* make the PC and the SP just two more registers.

Well, almost. No byte addressing via those two, auto{in,de}crement always 
by two. A friend was doing an FPGA version and that was one of the things 
that gave him no end of trouble.

>  But
> later so did the MC68000:  A6 was the stack pointer and A7 was the
> program counter.  I do *not* know it, but I would guess that in the
> PDP-11, since R7 was the PC and R6 was the SP... in most C compilers, R5
> would be used as the frame pointer and R4 would be the globals pointer. 
> Just a guess...

Frame pointer, yes. Not sure you need a globals pointer as you can use 
the PC, and PC-relative addressing.

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [next] | [standalone]

#161779

From	scott@slp53.sl.home (Scott Lurndal)
Date	2016-04-01 13:16 +0000
Message-ID	<ZwuLy.87498$111.3682@fx31.iad>
In reply to	#161758

Bob Eager <news0006@eager.cx> writes:
> git://git.gnome.org/pan2)
>X-Received-Bytes: 1729
>X-Received-Body-CRC: 668258961
>
>On Thu, 31 Mar 2016 14:45:16 -0500, Charles Richmond wrote:
>
>> The PDP-11 *did* make the PC and the SP just two more registers.
>
>Well, almost. No byte addressing via those two, auto{in,de}crement always 
>by two. A friend was doing an FPGA version and that was one of the things 
>that gave him no end of trouble.
>
>>  But
>> later so did the MC68000:  A6 was the stack pointer and A7 was the
>> program counter.  I do *not* know it, but I would guess that in the
>> PDP-11, since R7 was the PC and R6 was the SP... in most C compilers, R5
>> would be used as the frame pointer and R4 would be the globals pointer. 
>> Just a guess...
>
>Frame pointer, yes. Not sure you need a globals pointer as you can use 
>the PC, and PC-relative addressing.

 One can only use PC-relative for constants, as the text segment is
generally write-protected for security reasons.  Many psABI's will
specify a register to keep a pointer to thread-local data.  In ARM64
the register is 'TPIDR_EL0' which the OS will context switch with the
thread.  In intel, the %FS register is used as the base of the thread-local
storage and is also swapped on context switch (the %GS register is used
by the OS to store the thread-local base for OS data structures and there
is a fast MSR that the operating system can read/write to set %GS).

 Global data is generally frowned upon in modern threaded
software, but when used is addressed directly without a dedicated
base register.

[toc] | [prev] | [next] | [standalone]

#161784

From	Bob Eager <news0006@eager.cx>
Date	2016-04-01 14:30 +0000
Message-ID	<dm7f0jFflomU31@mid.individual.net>
In reply to	#161779

On Fri, 01 Apr 2016 13:16:41 +0000, Scott Lurndal wrote:

> Bob Eager <news0006@eager.cx> writes:
>> git://git.gnome.org/pan2)
>>X-Received-Bytes: 1729 X-Received-Body-CRC: 668258961
>>
>>On Thu, 31 Mar 2016 14:45:16 -0500, Charles Richmond wrote:
>>
>>> The PDP-11 *did* make the PC and the SP just two more registers.
>>
>>Well, almost. No byte addressing via those two, auto{in,de}crement
>>always by two. A friend was doing an FPGA version and that was one of
>>the things that gave him no end of trouble.
>>
>>>  But
>>> later so did the MC68000:  A6 was the stack pointer and A7 was the
>>> program counter.  I do *not* know it, but I would guess that in the
>>> PDP-11, since R7 was the PC and R6 was the SP... in most C compilers,
>>> R5 would be used as the frame pointer and R4 would be the globals
>>> pointer. Just a guess...
>>
>>Frame pointer, yes. Not sure you need a globals pointer as you can use
>>the PC, and PC-relative addressing.
> 
>  One can only use PC-relative for constants, as the text segment is
> generally write-protected for security reasons.

And, probably more importantly, to keep it 'pure' and shareable.

> Many psABI's will
> specify a register to keep a pointer to thread-local data.

Of course. That's another matter - not globals.

> In ARM64 the
> register is 'TPIDR_EL0' which the OS will context switch with the
> thread.  In intel, the %FS register is used as the base of the
> thread-local storage and is also swapped on context switch (the %GS
> register is used by the OS to store the thread-local base for OS data
> structures and there is a fast MSR that the operating system can
> read/write to set %GS).

That may be so, but of course that's a generalisation. Compilers and 
systems can use the registers any way they like, subject to conventions 
imposed elsewhere. I assume your comments are Linux-centric.

>  Global data is generally frowned upon in modern threaded
> software, but when used is addressed directly without a dedicated base
> register.

Exactly.



-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [next] | [standalone]

#161774

From	jmfbahciv <See.above@aol.com>
Date	2016-04-01 12:31 +0000
Message-ID	<PM00052F6B67D8DCCD@aca41056.ipt.aol.com>
In reply to	#161712

Scott Lurndal wrote:
> jmfbahciv <See.above@aol.com> writes:
>>Scott Lurndal wrote:
>
>>> why bother with ancient architectures, when one can obtain
>>> much more relevent data using modern processors and software?
>>
>>The machine code is readable and word oriented.
>
> There are no word machines in common use today.  All are byte
> machines.  Therefore, there is no reason that one would prefer
> a word-oriented machine as a learning tool (and if there was,
> I'd recommmend the Unisys clearpath libra architecture based
> on the B6500 which would be far less useless today as the PDP-10,
> since there are still libra's in production and need for programmers).
>
> X86 assembler is readable as well.  You have never even used it,
> how can you reject it so casually?

Sigh!  I wrote about what I know.  You wrote about what you know.
Now both are documented.

The code below is less readable than a PDP machine....hmmmm
maybe that's becuase of the difference between hex and
octal.

/BAH

>
> 00000000005d22e6 <c_condition::timedwait(c_lock*, timespec*)>:
>   5d22e6:       55                      push   %rbp
>   5d22e7:       48 89 e5                mov    %rsp,%rbp
>   5d22ea:       48 83 ec 20             sub    $0x20,%rsp
>   5d22ee:       48 89 7d f8             mov    %rdi,-0x8(%rbp)
>   5d22f2:       48 89 75 f0             mov    %rsi,-0x10(%rbp)
>   5d22f6:       48 89 55 e8             mov    %rdx,-0x18(%rbp)
>   5d22fa:       48 8b 4d f0             mov    -0x10(%rbp),%rcx
>   5d22fe:       48 8b 45 f8             mov    -0x8(%rbp),%rax
>   5d2302:       48 8b 55 e8             mov    -0x18(%rbp),%rdx
>   5d2306:       48 89 ce                mov    %rcx,%rsi
>   5d2309:       48 89 c7                mov    %rax,%rdi
>   5d230c:       e8 8f 0f ea ff          callq  4732a0
<pthread_cond_timedwait@plt>
>   5d2311:       c9                      leaveq
>   5d2312:       c3                      retq
>   5d2313:       90                      nop
>
> Looks a lot like the PDP-11, in fact.
>
> And here's arm aarch64:
>
> 0000000000401570 <register_tm_clones>:
>   401570:       b0000081        adrp    x1, 412000
<__frame_dummy_init_array_entry>
>   401574:       b0000080        adrp    x0, 412000
<__frame_dummy_init_array_entry>
>   401578:       910ae021        add     x1, x1, #0x2b8
>   40157c:       910ae000        add     x0, x0, #0x2b8
>   401580:       58000187        ldr     x7, 4015b0 <register_tm_clones+0x40>
>   401584:       cb000021        sub     x1, x1, x0
>   401588:       9343fc21        asr     x1, x1, #3
>   40158c:       8b41fc21        add     x1, x1, x1, lsr #63
>   401590:       9341fc21        asr     x1, x1, #1
>   401594:       eb1f003f        cmp     x1, xzr
>   401598:       fa5f10e4        ccmp    x7, xzr, #0x4, ne
>   40159c:       54000060        b.eq    4015a8 <register_tm_clones+0x38>
>   4015a0:       d61f00e0        br      x7
>   4015a4:       d503201f        nop
>   4015a8:       d65f03c0        ret
>   4015ac:       d503201f        nop
>
> To me, the x86 is more readable.  YMMV.
>
>>>
>>> Everything you describe above applies to modern processors.
>>>
>>> replace "ddt" with "gdb".
>>
>>Little steps first.  Byte addressing is not straight-forward
>>and instructions can wrap around.
>
> Say what?
>

[toc] | [prev] | [next] | [standalone]

#161777

From	Bob Eager <news0006@eager.cx>
Date	2016-04-01 13:02 +0000
Message-ID	<dm79qjFflomU29@mid.individual.net>
In reply to	#161712

On Thu, 31 Mar 2016 13:06:49 +0000, Scott Lurndal wrote:

> jmfbahciv <See.above@aol.com> writes:
>>Scott Lurndal wrote:
> 
>>> why bother with ancient architectures, when one can obtain much more
>>> relevent data using modern processors and software?
>>
>>The machine code is readable and word oriented.
> 
> There are no word machines in common use today.  All are byte machines. 
> Therefore, there is no reason that one would prefer a word-oriented
> machine as a learning tool (and if there was,
> I'd recommmend the Unisys clearpath libra architecture based on the
> B6500 which would be far less useless today as the PDP-10, since there
> are still libra's in production and need for programmers).
> 
> X86 assembler is readable as well.  You have never even used it,
> how can you reject it so casually?
> 
> 00000000005d22e6 <c_condition::timedwait(c_lock*, timespec*)>:
>   5d22e6:       55                      push   %rbp 5d22e7:       48 89
>   e5                mov    %rsp,%rbp 5d22ea:       48 83 ec 20          
>     sub    $0x20,%rsp 5d22ee:       48 89 7d f8             mov   
>   %rdi,-0x8(%rbp)
>   5d22f2:       48 89 75 f0             mov    %rsi,-0x10(%rbp)
>   5d22f6:       48 89 55 e8             mov    %rdx,-0x18(%rbp)
>   5d22fa:       48 8b 4d f0             mov    -0x10(%rbp),%rcx 5d22fe: 
>        48 8b 45 f8             mov    -0x8(%rbp),%rax 5d2302:       48
>   8b 55 e8             mov    -0x18(%rbp),%rdx 5d2306:       48 89 ce   
>               mov    %rcx,%rsi 5d2309:       48 89 c7                mov
>      %rax,%rdi 5d230c:       e8 8f 0f ea ff          callq  4732a0
>   <pthread_cond_timedwait@plt> 5d2311:       c9                     
>   leaveq 5d2312:       c3                      retq 5d2313:       90    
>                    nop
> 
> Looks a lot like the PDP-11, in fact.

It may LOOK like it - but nothing like. The PDP-11 is moderately 
orthogonal - the x86 isn't. PDP-11 instructions mostly work with any 
source and destination - the x86 ones don't.

> 
> And here's arm aarch64:
> 
> 0000000000401570 <register_tm_clones>:
>   401570:       b0000081        adrp    x1, 412000
>   <__frame_dummy_init_array_entry>
>   401574:       b0000080        adrp    x0, 412000
>   <__frame_dummy_init_array_entry>
>   401578:       910ae021        add     x1, x1, #0x2b8 40157c:      
>   910ae000        add     x0, x0, #0x2b8 401580:       58000187       
>   ldr     x7, 4015b0 <register_tm_clones+0x40> 401584:       cb000021   
>       sub     x1, x1, x0 401588:       9343fc21        asr     x1, x1,
>   #3 40158c:       8b41fc21        add     x1, x1, x1, lsr #63 401590:  
>       9341fc21        asr     x1, x1, #1 401594:       eb1f003f       
>   cmp     x1, xzr 401598:       fa5f10e4        ccmp    x7, xzr, #0x4,
>   ne 40159c:       54000060        b.eq    4015a8
>   <register_tm_clones+0x38>
>   4015a0:       d61f00e0        br      x7 4015a4:       d503201f       
>   nop 4015a8:       d65f03c0        ret 4015ac:       d503201f       
>   nop
> 
> To me, the x86 is more readable.  YMMV.

It certainly does. And I have used a dozen different assembly languages, 
at an absolute minimum.

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [next] | [standalone]

#161786

From	scott@slp53.sl.home (Scott Lurndal)
Date	2016-04-01 14:55 +0000
Message-ID	<KZvLy.67$Vf2.30@fx24.iad>
In reply to	#161777

Bob Eager <news0006@eager.cx> writes:

>
>It may LOOK like it - but nothing like. The PDP-11 is moderately 
>orthogonal - the x86 isn't. PDP-11 instructions mostly work with any 
>source and destination - the x86 ones don't.

The x86 instructions mostly work with any source and destination as well.
This isn't 1980 anymore.

>
>> 
>> And here's arm aarch64:
>> 
>> 0000000000401570 <register_tm_clones>:
>>   401570:       b0000081        adrp    x1, 412000
>>   <__frame_dummy_init_array_entry>
>>   401574:       b0000080        adrp    x0, 412000
>>   <__frame_dummy_init_array_entry>
>>   401578:       910ae021        add     x1, x1, #0x2b8 40157c:      
>>   910ae000        add     x0, x0, #0x2b8 401580:       58000187       
>>   ldr     x7, 4015b0 <register_tm_clones+0x40> 401584:       cb000021   
>>       sub     x1, x1, x0 401588:       9343fc21        asr     x1, x1,
>>   #3 40158c:       8b41fc21        add     x1, x1, x1, lsr #63 401590:  
>>       9341fc21        asr     x1, x1, #1 401594:       eb1f003f       
>>   cmp     x1, xzr 401598:       fa5f10e4        ccmp    x7, xzr, #0x4,
>>   ne 40159c:       54000060        b.eq    4015a8
>>   <register_tm_clones+0x38>
>>   4015a0:       d61f00e0        br      x7 4015a4:       d503201f       
>>   nop 4015a8:       d65f03c0        ret 4015ac:       d503201f       
>>   nop
>> 
>> To me, the x86 is more readable.  YMMV.
>
>It certainly does. And I have used a dozen different assembly languages, 
>at an absolute minimum.

Too bad your posting client mangles the quoted article.

I've programmed (for pay) in assembler on the PDP-8, PDP-11, Vax-11/780,
Itel AS-6 (running MVS), Burroughs medium systems (as an operating
system engineer), 6502, 68K, 88100, MIPS, Intel (386 to current Xeons) and ARM64 in
the last 40 years.

They all have their quirks.  I was never fond of the 370 instruction
set myself.  I did quite like the VAX instruction set, I found MOVC5
particularly useful having some characteristics in common with the Burroughs
data movement instructions.

[toc] | [prev] | [next] | [standalone]

#161790

From	Bob Eager <news0006@eager.cx>
Date	2016-04-01 17:24 +0000
Message-ID	<dm7p70FflomU33@mid.individual.net>
In reply to	#161786

On Fri, 01 Apr 2016 14:55:38 +0000, Scott Lurndal wrote:

> I've programmed (for pay) in assembler on the PDP-8, PDP-11, Vax-11/780,
> Itel AS-6 (running MVS), Burroughs medium systems (as an operating
> system engineer), 6502, 68K, 88100, MIPS, Intel (386 to current Xeons)
> and ARM64 in the last 40 years.

Just trying to remember. I think nearly all of mine were for pay.
ICT 1900 (doubt you'd have come across that), Elliott 4130 (ditto), 
PDP-10 (beautifully orthogonal), PDP-8 [for fun; I have a hardware 
replica], PDP-11 (including a large chunk of homebrew operating system), 
VAX (lots of them, including device drivers), 4004, 8080, Z80, 6502, 
6800, 68000, Intel (8086, 80386, 80486, etc. up to present, including a 
homebrew operating system), 370 (operating system, and also boot code 
because the version of VM I was developing it under didn't play by the 
rules), ICL 2900 (operating system and indeed microcode), Atmel (in the 
Arduino), and just started on the ARM.

> They all have their quirks.  I was never fond of the 370 instruction set
> myself.

Nor me. But I was being paid a lot of money for it!

> I did quite like the VAX instruction set, I found MOVC5
> particularly useful having some characteristics in common with the
> Burroughs data movement instructions.

Me too. It could occupy a ridiculous number of bytes if you had stupidly 
complicated operands. I have three VAXes here in the house, along with 
the PDP-8 replica and four PDP-11s.

The ICL 2900 is an interesting architecture. Two base registers, a stack 
front and frame pointer, one index register and one variable size 
accumulator. Very nice for compiler writers. If interested:
  http://www.fujitsu.com/uk/Images/icl-2900-series-by-jk-buckle.pdf

Mostly retired now but still like playing in assembler.

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [next] | [standalone]

#161797

From	Peter Flass <peter_flass@yahoo.com>
Date	2016-04-01 17:05 -0400
Message-ID	<1818716705.481237126.975555.peter_flass-yahoo.com@news.eternal-september.org>
In reply to	#161786

Scott Lurndal <scott@slp53.sl.home> wrote:
> Bob Eager <news0006@eager.cx> writes:
> 
>> 
>> It may LOOK like it - but nothing like. The PDP-11 is moderately 
>> orthogonal - the x86 isn't. PDP-11 instructions mostly work with any 
>> source and destination - the x86 ones don't.
> 
> The x86 instructions mostly work with any source and destination as well.
> This isn't 1980 anymore.
> 
>> 
>>> 
>>> And here's arm aarch64:
>>> 
>>> 0000000000401570 <register_tm_clones>:
>>> 401570:       b0000081        adrp    x1, 412000
>>> <__frame_dummy_init_array_entry>
>>> 401574:       b0000080        adrp    x0, 412000
>>> <__frame_dummy_init_array_entry>
>>> 401578:       910ae021        add     x1, x1, #0x2b8 40157c:      
>>> 910ae000        add     x0, x0, #0x2b8 401580:       58000187       
>>> ldr     x7, 4015b0 <register_tm_clones+0x40> 401584:       cb000021   
>>> sub     x1, x1, x0 401588:       9343fc21        asr     x1, x1,
>>> #3 40158c:       8b41fc21        add     x1, x1, x1, lsr #63 401590:  
>>> 9341fc21        asr     x1, x1, #1 401594:       eb1f003f       
>>> cmp     x1, xzr 401598:       fa5f10e4        ccmp    x7, xzr, #0x4,
>>> ne 40159c:       54000060        b.eq    4015a8
>>> <register_tm_clones+0x38>
>>> 4015a0:       d61f00e0        br      x7 4015a4:       d503201f       
>>> nop 4015a8:       d65f03c0        ret 4015ac:       d503201f       
>>> nop
>>> 
>>> To me, the x86 is more readable.  YMMV.
>> 
>> It certainly does. And I have used a dozen different assembly languages, 
>> at an absolute minimum.
> 
> Too bad your posting client mangles the quoted article.
> 
> I've programmed (for pay) in assembler on the PDP-8, PDP-11, Vax-11/780,
> Itel AS-6 (running MVS), Burroughs medium systems (as an operating
> system engineer), 6502, 68K, 88100, MIPS, Intel (386 to current Xeons) and ARM64 in
> the last 40 years.
> 
> They all have their quirks.  I was never fond of the 370 instruction
> set myself.  I did quite like the VAX instruction set, I found MOVC5
> particularly useful having some characteristics in common with the Burroughs
> data movement instructions.
> 

I liked the VAX too, but it always seemed to me that a large portion of the
instruction set would be unused by the average programmer.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#161801

From	Bob Eager <news0006@eager.cx>
Date	2016-04-01 23:11 +0000
Message-ID	<dm8dh2FflomU35@mid.individual.net>
In reply to	#161797

On Fri, 01 Apr 2016 17:05:02 -0400, Peter Flass wrote:

> Scott Lurndal <scott@slp53.sl.home> wrote:
>> Bob Eager <news0006@eager.cx> writes:
>> 
>> 
>>> It may LOOK like it - but nothing like. The PDP-11 is moderately
>>> orthogonal - the x86 isn't. PDP-11 instructions mostly work with any
>>> source and destination - the x86 ones don't.
>> 
>> The x86 instructions mostly work with any source and destination as
>> well.
>> This isn't 1980 anymore.
>> 
>> 
>>> 
>>>> And here's arm aarch64:
>>>> 
>>>> 0000000000401570 <register_tm_clones>:
>>>> 401570:       b0000081        adrp    x1, 412000
>>>> <__frame_dummy_init_array_entry>
>>>> 401574:       b0000080        adrp    x0, 412000
>>>> <__frame_dummy_init_array_entry>
>>>> 401578:       910ae021        add     x1, x1, #0x2b8 40157c: 910ae000
>>>>        add     x0, x0, #0x2b8 401580:       58000187 ldr     x7,
>>>> 4015b0 <register_tm_clones+0x40> 401584:       cb000021 sub     x1,
>>>> x1, x0 401588:       9343fc21        asr     x1, x1,
>>>> #3 40158c:       8b41fc21        add     x1, x1, x1, lsr #63 401590:
>>>> 9341fc21        asr     x1, x1, #1 401594:       eb1f003f cmp     x1,
>>>> xzr 401598:       fa5f10e4        ccmp    x7, xzr, #0x4,
>>>> ne 40159c:       54000060        b.eq    4015a8
>>>> <register_tm_clones+0x38>
>>>> 4015a0:       d61f00e0        br      x7 4015a4:       d503201f nop
>>>> 4015a8:       d65f03c0        ret 4015ac:       d503201f nop
>>>> 
>>>> To me, the x86 is more readable.  YMMV.
>>> 
>>> It certainly does. And I have used a dozen different assembly
>>> languages,
>>> at an absolute minimum.
>> 
>> Too bad your posting client mangles the quoted article.
>> 
>> I've programmed (for pay) in assembler on the PDP-8, PDP-11,
>> Vax-11/780,
>> Itel AS-6 (running MVS), Burroughs medium systems (as an operating
>> system engineer), 6502, 68K, 88100, MIPS, Intel (386 to current Xeons)
>> and ARM64 in the last 40 years.
>> 
>> They all have their quirks.  I was never fond of the 370 instruction
>> set myself.  I did quite like the VAX instruction set, I found MOVC5
>> particularly useful having some characteristics in common with the
>> Burroughs data movement instructions.
>> 
>> 
> I liked the VAX too, but it always seemed to me that a large portion of
> the instruction set would be unused by the average programmer.

I agree. Even compiler writers found it hard (I wrote a VAX compiler)!



-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [next] | [standalone]

#161983

From	scott@slp53.sl.home (Scott Lurndal)
Date	2016-04-04 13:07 +0000
Message-ID	<aGtMy.13935$4s2.4845@fx01.iad>
In reply to	#161801

Bob Eager <news0006@eager.cx> writes:
> git://git.gnome.org/pan2)
>X-Received-Bytes: 3378
>X-Received-Body-CRC: 3832650103
>
>On Fri, 01 Apr 2016 17:05:02 -0400, Peter Flass wrote:
>
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Bob Eager <news0006@eager.cx> writes:
>>> 
>>> 
>>>> It may LOOK like it - but nothing like. The PDP-11 is moderately
>>>> orthogonal - the x86 isn't. PDP-11 instructions mostly work with any
>>>> source and destination - the x86 ones don't.
>>> 
>>> The x86 instructions mostly work with any source and destination as
>>> well.
>>> This isn't 1980 anymore.
>>> 
>>> 

>>> 
>>> I've programmed (for pay) in assembler on the PDP-8, PDP-11,
>>> Vax-11/780,
>>> Itel AS-6 (running MVS), Burroughs medium systems (as an operating
>>> system engineer), 6502, 68K, 88100, MIPS, Intel (386 to current Xeons)
>>> and ARM64 in the last 40 years.
>>> 
>>> They all have their quirks.  I was never fond of the 370 instruction
>>> set myself.  I did quite like the VAX instruction set, I found MOVC5
>>> particularly useful having some characteristics in common with the
>>> Burroughs data movement instructions.
>>> 
>>> 
>> I liked the VAX too, but it always seemed to me that a large portion of
>> the instruction set would be unused by the average programmer.
>
>I agree. Even compiler writers found it hard (I wrote a VAX compiler)!

That said, for many of the instructions (e.g. POLY), there were no
source-language features that would trigger generation.   I wrote a PASCAL
compiler that generated VAX object code back in the early 80's;  We had
the choice of PDP-11 or VAX as the target, and it turns out it was much
easier to generate code for the VAX when compared to the PDP-11 (32-bit vs. 16-bit
mainly).

[toc] | [prev] | [next] | [standalone]

#161990

From	Peter Flass <peter_flass@yahoo.com>
Date	2016-04-04 09:16 -0400
Message-ID	<383809692.481468363.659966.peter_flass-yahoo.com@news.eternal-september.org>
In reply to	#161983

Scott Lurndal <scott@slp53.sl.home> wrote:
> Bob Eager <news0006@eager.cx> writes:
>> git://git.gnome.org/pan2)
>> X-Received-Bytes: 3378
>> X-Received-Body-CRC: 3832650103
>> 
>> On Fri, 01 Apr 2016 17:05:02 -0400, Peter Flass wrote:
>> 
>>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> Bob Eager <news0006@eager.cx> writes:
>>>> 
>>>> 
>>>>> It may LOOK like it - but nothing like. The PDP-11 is moderately
>>>>> orthogonal - the x86 isn't. PDP-11 instructions mostly work with any
>>>>> source and destination - the x86 ones don't.
>>>> 
>>>> The x86 instructions mostly work with any source and destination as
>>>> well.
>>>> This isn't 1980 anymore.
>>>> 
>>>> 
> 
>>>> 
>>>> I've programmed (for pay) in assembler on the PDP-8, PDP-11,
>>>> Vax-11/780,
>>>> Itel AS-6 (running MVS), Burroughs medium systems (as an operating
>>>> system engineer), 6502, 68K, 88100, MIPS, Intel (386 to current Xeons)
>>>> and ARM64 in the last 40 years.
>>>> 
>>>> They all have their quirks.  I was never fond of the 370 instruction
>>>> set myself.  I did quite like the VAX instruction set, I found MOVC5
>>>> particularly useful having some characteristics in common with the
>>>> Burroughs data movement instructions.
>>>> 
>>>> 
>>> I liked the VAX too, but it always seemed to me that a large portion of
>>> the instruction set would be unused by the average programmer.
>> 
>> I agree. Even compiler writers found it hard (I wrote a VAX compiler)!
> 
> That said, for many of the instructions (e.g. POLY), there were no
> source-language features that would trigger generation.   I wrote a PASCAL
> compiler that generated VAX object code back in the early 80's;  We had
> the choice of PDP-11 or VAX as the target, and it turns out it was much
> easier to generate code for the VAX when compared to the PDP-11 (32-bit vs. 16-bit
> mainly).
> 

I always got hung up on one- two- or three-address instructions.  In many
cases you could generate code to do the same thing in a number of ways.  I
suppose if I had done a lot of VAX assembler my coding would have fallen
into a constant pattern, but I kept trying to decide which was better.

-- 
Pete

[toc] | [prev] | [next] | [standalone]

#161993

From	Bob Eager <news0006@eager.cx>
Date	2016-04-04 13:42 +0000
Message-ID	<dmf9atFs66uU7@mid.individual.net>
In reply to	#161983

On Mon, 04 Apr 2016 13:07:18 +0000, Scott Lurndal wrote:

> Bob Eager <news0006@eager.cx> writes:
>> git://git.gnome.org/pan2)
>>X-Received-Bytes: 3378 X-Received-Body-CRC: 3832650103
>>
>>On Fri, 01 Apr 2016 17:05:02 -0400, Peter Flass wrote:
>>
>>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> Bob Eager <news0006@eager.cx> writes:
>>>> 
>>>> 
>>>>> It may LOOK like it - but nothing like. The PDP-11 is moderately
>>>>> orthogonal - the x86 isn't. PDP-11 instructions mostly work with any
>>>>> source and destination - the x86 ones don't.
>>>> 
>>>> The x86 instructions mostly work with any source and destination as
>>>> well.
>>>> This isn't 1980 anymore.
>>>> 
>>>> 
>>>> 
> 
>>>> I've programmed (for pay) in assembler on the PDP-8, PDP-11,
>>>> Vax-11/780,
>>>> Itel AS-6 (running MVS), Burroughs medium systems (as an operating
>>>> system engineer), 6502, 68K, 88100, MIPS, Intel (386 to current
>>>> Xeons)
>>>> and ARM64 in the last 40 years.
>>>> 
>>>> They all have their quirks.  I was never fond of the 370 instruction
>>>> set myself.  I did quite like the VAX instruction set, I found MOVC5
>>>> particularly useful having some characteristics in common with the
>>>> Burroughs data movement instructions.
>>>> 
>>>> 
>>> I liked the VAX too, but it always seemed to me that a large portion
>>> of the instruction set would be unused by the average programmer.
>>
>>I agree. Even compiler writers found it hard (I wrote a VAX compiler)!
> 
> That said, for many of the instructions (e.g. POLY), there were no
> source-language features that would trigger generation.   I wrote a
> PASCAL compiler that generated VAX object code back in the early 80's; 
> We had the choice of PDP-11 or VAX as the target, and it turns out it
> was much easier to generate code for the VAX when compared to the PDP-11
> (32-bit vs. 16-bit mainly).

Oh, indeed. I did the same compiler for both, as it happens.



-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

[toc] | [prev] | [next] | [standalone]

#161697

From	Morten Reistad <first@Last.name.Invalid>
Date	2016-03-30 20:07 +0200
Message-ID	<58htsc-6b1.ln1@sambook.reistad.name>
In reply to	#161641

In article <PM00052F44B0C5159C@aca40b23.ipt.aol.com>,
jmfbahciv  <See.above@aol.com> wrote:
>Mike Spencer wrote:
>>
>> Neo Fortune <serenity3043@gmail.com> writes:
>>
>>> Thanks...
>>>
>>> The Art of Computer Programming By Donald Knuth Sounds The Ticket
>>
>> Overlooking those who believe that Basic isn't programming, I learned
>> to program dicking around with Basic on an Apple ][ and an Osborne 1.
>> Then I read K&R straight through until my head threatened to explode
>> (near the end, somewhere around struct bitfields) and started to write
>> C code -- on the Osborne.
>>
>> Once you have a basic (not Basic) notion of what bits & bytes are, IMHO
>> K&R will get you   doing interesting things pretty quick.
>>
>> But then, I'm an amateur (in the best sense), not a professional
>> hacker.
>>
>
>One way to understand programming bits and bytes is to install
>an emulator for the PDP-8 and play with it.  Graduating to PDP-10
>machines would offer a more complex OS and services.  I don't
>recall DEC documenting the algorithms developed for monitor
>(kernals) and device/network contollers and devices.
>The latter also shows how to do memrory management of all flavors
>and buffered mode I/O (which was completely missing from MSoft's
>bit bucket).
>
>GETting any EXE on a PDP-10, then DDTing it, gives access
>the entire "app" the user has pulled into core.  Just
>stepping through the locations using the <LF> character
>gives a nice introduction to addresses, contents of
>addresses, data, code and bytes.

Well, provided you have read access to the .exe. 

And, the early compiler output was pretty readable as 
disassembled code. This was less and less the case for the
higher optimisations levels as the versions kept coming, and
it is not the case at all with modern x86/thumb code.

Linux or FreeBSD are in themselves pretty good programming
platforms, given a few dozen repository downloads from a
standard install. They even have smalltalk.

-- mrr

[toc] | [prev] | [next] | [standalone]

#161413

From	Walter Banks <walter@bytecraft.com>
Date	2016-03-23 12:27 -0400
Message-ID	<ncug5j$ga8$1@gioia.aioe.org>
In reply to	#161395

On 23/03/2016 5:31 AM, Neo Fortune wrote:
 > There's One In Particular That Covers Different Algorithms
 >
There are a lot of algorithm collections on line. Google around and they
will pop up.

w..

[toc] | [prev] | [next] | [standalone]

Page 20 of 21 — ← Prev page 1 … 18 19 [20] 21 Next page →

csiph-web

Which Books Can You Recommend For Learning Computer Programming?

Contents

#161755

#161778

#161793

#161836

#161854

#161888

#161758

#161779

#161784

#161774

#161777

#161786

#161790

#161797

#161801

#161983

#161990

#161993

#161697

#161413