On 7/25/2023 8:52 PM, Arne Vajhøj wrote:
> On 7/24/2023 4:38 AM, hb@end.of.inter.net wrote:
>> On Monday, July 24, 2023 at 1:31:46 AM UTC+2, Arne Vajhøj wrote:
>>> But difficult to check the difference between /OPT and /NOOPT,
>>> because for some unknown reason /LIST/MACH does not list the
>>> generated code.
>>
>> MACRO-32 on x86?
>
> Yes.
>
>> You can always (except you compile with /NOOBJECT :-) get the machine
>> code listing with ANALYZE/OBJECT/DISASSEMBLE.
>
> I did not know that.
>
> But also weird.
>
> I do not see a difference between /OPT and /NOOPT at all.

Tested with a trivial piece of code:

.title str
.psect $CODE quad,pic,con,lcl,shr,exe,nowrt
.entry str_int_val,^m<r2,r3,r4>
movl B^4(ap),r0
movl B^4(r0),r1 ; address of string
movzwl (r0),r2 ; length of string
movl #0,r0 ; value=0
tstl r2 ; test if empty string
bleq 400$
clrl r3
movl #1,r4 ; scale=1
100$: movb (r1),r3
cmpb #32,r3 ; test if " " => skip
beql 300$
cmpb #45,r3 ; test if "-" => scale=-1*scale
bneq 200$
mull2 #-1,r4
brb 300$
200$: subb2 #48,r3 ; value=10*value+digit
mull2 #10,r0
addl2 r3,r0
300$: incl r1
decl r2
tstl r2
bgtr 100$
mull2 r4,r0 ; value=value*scale
400$: movl r0,@B^8(ap)
ret
.end

with /NOOPT:

.section
$CODE, "ax", "progbits" # EXE,SHR
.align 16
.cfi_startproc
STR_INT_VAL::
55 00000000: pushq %rbp
# 000003
E5 89 48 00000001: movq %rsp,%rbp
53 00000004: pushq %rbx
57 41 00000005: pushq %r15
56 41 00000007: pushq %r14
55 41 00000009: pushq %r13
DC B6 0F 0000000B: movzbl %ah,%ebx
00 00 00 00 E8 0000000E: callq
LIB$ALPHA_REG_VECTOR_BASE@PLT
93 48 00000013: xchgq %rax,%rbx
54 41 00000015: pushq %r12
00 00 00 80 BB 89 48 00000017: movq %rdi,00000080(%rbx)
00 00 00 88 B3 89 48 0000001E: movq %rsi,00000088(%rbx)
20 73 FF 00000025: pushq 20(%rbx)
18 73 FF 00000028: pushq 18(%rbx)
10 73 FF 0000002B: pushq 10(%rbx)
00 6A 0000002E: pushq $00
E4 89 49 00000030: movq %rsp,%r12
_$$L1:
00 00 00 80 93 63 4C 00000033: movslq
00000080(%rbx),%r10 # 000004
13 89 4C 0000003A: movq %r10,(%rbx)
13 8B 4C 0000003D: movq (%rbx),%r10
# 000005
04 5A 63 4D 00000040: movslq 04(%r10),%r11
08 5B 89 4C 00000044: movq %r11,08(%rbx)
13 8B 4C 00000048: movq (%rbx),%r10
# 000006
1A B7 0F 4D 0000004B: movzwq (%r10),%r11
10 5B 89 4C 0000004F: movq %r11,10(%rbx)
00 00 00 00 03 C7 48 00000053: movq
$00000000,(%rbx) # 000007
10 53 63 4C 0000005A: movslq 10(%rbx),%r10
# 000008
00 FA 83 41 0000005E: cmpl $00,%r10d
9F 00000062: lahf
C7 89 41 66 00000063: movw %ax,%r15w
F8 89 44 66 00000067: movw %r15w,%ax
# 000009
FF FE E0 81 66 0000006B: andw $-0002,%ax
9E 00000070: sahf
00 00 00 BC 8E 0F 00000071: jle 3_400$
C0 31 48 00000077: xorq %rax,%rax
# 000010
18 43 89 48 0000007A: movq %rax,18(%rbx)
00 00 00 01 20 43 C7 48 0000007E: movq
$00000001,20(%rbx) # 000011
3_100$:
08 53 8B 4C 00000086: movq 08(%rbx),%r10
# 000012
1A B6 0F 4D 0000008A: movzbq (%r10),%r11
18 5B 88 44 0000008E: movb %r11l,18(%rbx)
18 53 B6 0F 4C 00000092: movzbq 18(%rbx),%r10
# 000013
00 20 BB 41 66 00000097: movw $0020,%r11w
D2 BE 0F 4D 0000009C: movsbq %r10l,%r10
D3 39 45 66 000000A0: cmpw %r10w,%r11w
9F 000000A4: lahf
C7 89 41 66 000000A5: movw %ax,%r15w
F8 89 44 66 000000A9: movw %r15w,%ax
# 000014
9E 000000AD: sahf
00 00 00 4A 84 0F 000000AE: je 3_300$
18 53 B6 0F 4C 000000B4: movzbq 18(%rbx),%r10
# 000015
00 2D BB 41 66 000000B9: movw $002D,%r11w
D2 BE 0F 4D 000000BE: movsbq %r10l,%r10
D3 39 45 66 000000C2: cmpw %r10w,%r11w
9F 000000C6: lahf
C7 89 41 66 000000C7: movw %ax,%r15w
F8 89 44 66 000000CB: movw %r15w,%ax
# 000016
9E 000000CF: sahf
00 00 00 0A 85 0F 000000D0: jne 3_200$
00 00 00 8B E9 000000D6: jmpq _$$L3
# 000016
00 00 00 86 E9 000000DB: jmpq _$$L3
3_200$:
30 18 6B 80 000000E0: subb $30,18(%rbx)
# 000019
0A 13 6B 44 000000E4: imul
$0A,(%rbx),%r10d # 000020
DA 63 4D 000000E8: movslq %r10d,%r11
1B 89 4C 000000EB: movq %r11,(%rbx)
18 53 63 4C 000000EE: movslq 18(%rbx),%r10
# 000021
1B 8B 4C 000000F2: movq (%rbx),%r11
D3 01 45 000000F5: addl %r10d,%r11d
CB 63 4D 000000F8: movslq %r11d,%r9
0B 89 4C 000000FB: movq %r9,(%rbx)
3_300$:
01 08 43 83 48 000000FE: addq $01,08(%rbx)
# 000022
01 10 6B 83 48 00000103: subq $01,10(%rbx)
# 000023
10 53 63 4C 00000108: movslq 10(%rbx),%r10
# 000024
00 FA 83 41 0000010C: cmpl $00,%r10d
9F 00000110: lahf
C7 89 41 66 00000111: movw %ax,%r15w
F8 89 44 66 00000115: movw %r15w,%ax
# 000025
FF FE E0 81 66 00000119: andw $-0002,%ax
9E 0000011E: sahf
FF FF FF 61 8F 0F 0000011F: jg 3_100$
20 53 63 4C 00000125: movslq 20(%rbx),%r10
# 000026
13 AF 0F 44 00000129: imull (%rbx),%r10d
DA 63 4D 0000012D: movslq %r10d,%r11
1B 89 4C 00000130: movq %r11,(%rbx)
3_400$:
13 63 4C 00000133: movslq (%rbx),%r10
# 000027
00 00 00 88 9B 8B 4C 00000136: movq 00000088(%rbx),%r11
13 89 45 0000013D: movl %r10d,(%r11)
_$$_0:
C0 65 8D 48 00000140: leaq -40(%rbp),%rsp
# 000028
FE 00 00 00 F0 A3 80 00000144: andb $-02,000000F0(%rbx)
10 43 8F 0000014B: popq 10(%rbx)
18 43 8F 0000014E: popq 18(%rbx)
20 43 8F 00000151: popq 20(%rbx)
03 8B 48 00000154: movq (%rbx),%rax
08 53 8B 48 00000157: movq 08(%rbx),%rdx
5C 41 0000015B: popq %r12
5D 41 0000015D: popq %r13
5E 41 0000015F: popq %r14
5F 41 00000161: popq %r15
5B 00000163: popq %rbx
5D 00000164: popq %rbp
C3 00000165: retq
_$$L3:
FF 20 53 6B 44 00000166: imul
$-01,20(%rbx),%r10d # 000017
DA 63 4D 0000016B: movslq %r10d,%r11
20 5B 89 4C 0000016E: movq %r11,20(%rbx)
FF FF FF 87 E9 00000172: jmpq 3_300$
# 000018
.cfi_endproc

On 26/07/2023 01:52, Arne Vajhøj wrote:
> On 7/24/2023 4:38 AM, hb@end.of.inter.net wrote:
>> On Monday, July 24, 2023 at 1:31:46 AM UTC+2, Arne Vajhøj wrote:
>>> But difficult to check the difference between /OPT and /NOOPT,
>>> because for some unknown reason /LIST/MACH does not list the
>>> generated code.
>>
>> MACRO-32 on x86?
>
> Yes.
>
>> You can always (except you compile with /NOOBJECT :-) get the machine
>> code listing with ANALYZE/OBJECT/DISASSEMBLE.
>
> I did not know that.
>
> But also weird.
>
> I do not see a difference between /OPT and /NOOPT at all.
>
> Arne
>

But id optimisation of macro a thing? I thought it was only relevant to
higher level languages...

Never used macro32 - I gave up any low level language after playing with
Zilog Z80 code in the early 80s

--
Chris

On 7/25/2023 9:14 PM, Chris Townley wrote:
> On 26/07/2023 01:52, Arne Vajhøj wrote:
>> On 7/24/2023 4:38 AM, hb@end.of.inter.net wrote:
>>> On Monday, July 24, 2023 at 1:31:46 AM UTC+2, Arne Vajhøj wrote:
>>>> But difficult to check the difference between /OPT and /NOOPT,
>>>> because for some unknown reason /LIST/MACH does not list the
>>>> generated code.
>>>
>>> MACRO-32 on x86?
>>
>> Yes.
>>
>>> You can always (except you compile with /NOOBJECT :-) get the machine
>>> code listing with ANALYZE/OBJECT/DISASSEMBLE.
>>
>> I did not know that.
>>
>> But also weird.
>>
>> I do not see a difference between /OPT and /NOOPT at all.
>
> But id optimisation of macro a thing? I thought it was only relevant to
> higher level languages...
>
> Never used macro32 - I gave up any low level language after playing with
> Zilog Z80 code in the early 80s

It did not make any sense back on VAX when it was real assembler.

It does make some sense on the newer platforms where it is a
compiler.

Arne

On Tuesday, July 25, 2023 at 9:14:26 PM UTC-4, Chris Townley wrote:
> On 26/07/2023 01:52, Arne Vajhøj wrote:
> > On 7/24/2023 4:38 AM, h...@end.of.inter.net wrote:
> >> On Monday, July 24, 2023 at 1:31:46 AM UTC+2, Arne Vajhøj wrote:
> >>> But difficult to check the difference between /OPT and /NOOPT,
> >>> because for some unknown reason /LIST/MACH does not list the
> >>> generated code.
> >>
> >> MACRO-32 on x86?
> >
> > Yes.
> >
> >> You can always (except you compile with /NOOBJECT :-) get the machine
> >> code listing with ANALYZE/OBJECT/DISASSEMBLE.
> >
> > I did not know that.
> >
> > But also weird.
> >
> > I do not see a difference between /OPT and /NOOPT at all.
> >
> > Arne
> >
> But id optimisation of macro a thing? I thought it was only relevant to
> higher level languages...
>
> Never used macro32 - I gave up any low level language after playing with
> Zilog Z80 code in the early 80s
>
> --
> Chris
Yes, there is some limited optimization in the Macro compiler itself. It will attempt
to hoist some memory fetches out of loops and such. In general, /OPT enables the
GEM peephole optimizer at the instruction level.

For x86, the backend organization is much different and we are interfacing past any
sort of peephole or scheduling level. XMACRO is essentially a fancy assembler. It is
expected to do things like peephole optimizations and select different instructions
based on micro-architecture. We do very little of that. My belief that the added benefit
is almost not worth mentioning.

On 7/25/2023 8:53 PM, Arne Vajhøj wrote:
> On 7/25/2023 8:52 PM, Arne Vajhøj wrote:
>> On 7/24/2023 4:38 AM, hb@end.of.inter.net wrote:
>>> On Monday, July 24, 2023 at 1:31:46 AM UTC+2, Arne Vajhøj wrote:
>>>> But difficult to check the difference between /OPT and /NOOPT,
>>>> because for some unknown reason /LIST/MACH does not list the
>>>> generated code.
>>>
>>> MACRO-32 on x86?
>>
>> Yes.
>>
>>> You can always (except you compile with /NOOBJECT :-) get the machine
>>> code listing with ANALYZE/OBJECT/DISASSEMBLE.
>>
>> I did not know that.
>>
>> But also weird.
>>
>> I do not see a difference between /OPT and /NOOPT at all.
>
> Tested with a trivial piece of code:
>
>         .title  str
>         .psect  $CODE quad,pic,con,lcl,shr,exe,nowrt
>         .entry  str_int_val,^m<r2,r3,r4>
>         movl    B^4(ap),r0
>         movl    B^4(r0),r1              ; address of string
>         movzwl  (r0),r2                 ; length of string
>         movl    #0,r0                   ; value=0
>         tstl    r2                      ; test if empty string
>         bleq    400$
>         clrl    r3
>         movl    #1,r4                   ; scale=1
> 100$:   movb    (r1),r3
>         cmpb    #32,r3                  ; test if " " => skip
>         beql    300$
>         cmpb    #45,r3                  ; test if "-" => scale=-1*scale
>         bneq    200$
>         mull2   #-1,r4
>         brb     300$
> 200$:   subb2   #48,r3                  ; value=10*value+digit
>         mull2   #10,r0
>         addl2   r3,r0
> 300$:   incl    r1
>         decl    r2
>         tstl    r2
>         bgtr    100$
>         mull2   r4,r0                   ; value=value*scale
> 400$:   movl    r0,@B^8(ap)
>         ret
>         .end

On Alpha the code is slightly different.

with /NOOPT:

.PSECT $CODE, QUAD, PIC, CON, REL,
LCL, SHR, EXE, RD, NOWRT
0000 STR_INT_VAL::
23DEFFD0 0000 LDA SP, -48(SP)
B77E0000 0004 STQ R27, (SP)
B75E0008 0008 STQ R26, 8(SP)
B45E0010 000C STQ R2, 16(SP)
B47E0018 0010 STQ R3, 24(SP)
B49E0020 0014 STQ R4, 32(SP)
B7BE0028 0018 STQ FP, 40(SP)
47FE041D 001C MOV SP, FP
0020 $L1:
43F00000 0020 SEXTL R16, R0
; 000004
A0200004 0024 LDL R1, 4(R0)
; 000005
47E10401 0028 MOV R1, R1
2C400000 002C LDQ_U R2, (R0)
; 000006
484002C2 0030 EXTWL R2, R0, R2
F0000028 0034 BLBS R0, $L4
0038 $L5:
47E20402 0038 MOV R2, R2
201F0000 003C LDA R0, (R31)
; 000007
EC400019 0040 BLE R2, 3_400$
; 000009
47FF0403 0044 MOV R31, R3
; 000010
209F0001 0048 LDA R4, 1(R31)
; 000011
004C 3_100$:
; 000012
2F010000 004C LDQ_U R24, (R1)
4B0100D8 0050 EXTBL R24, R1, R24
447FF103 0054 BIC R3, 255, R3
44780403 0058 BIS R3, R24, R3
447FF016 005C AND R3, 255, R22
; 000013
42C41532 0060 SUBQ R22, 32, R18
E640000C 0064 BEQ R18, 3_300$
; 000014
447FF01A 0068 AND R3, 255, R26
; 000015
4345B532 006C SUBQ R26, 45, R18
F6400002 0070 BNE R18, 3_200$
; 000016
C3E00015 0074 BR $L3
C3E00014 0078 BR $L3
; 000017
007C 3_200$:
; 000019
40661139 007C SUBL R3, 48, R25
473FF019 0080 AND R25, 255, R25
447FF103 0084 BIC R3, 255, R3
44790403 0088 BIS R3, R25, R3
40000000 008C ADDL R0, R0, R0
; 000020
40000040 0090 S4ADDL R0, R0, R0
40030000 0094 ADDL R0, R3, R0
; 000021
0098 3_300$:
; 000022
40203001 0098 ADDL R1, 1, R1
40403122 009C SUBL R2, 1, R2
; 000023
FC5FFFEA 00A0 BGT R2, 3_100$
; 000025
4C040000 00A4 MULL R0, R4, R0
; 000026
00A8 3_400$:
; 000027
B0110000 00A8 STL R0, (R17)
00AC $L2:
; 000028
47FD041E 00AC MOV FP, SP
A79E0008 00B0 LDQ R28, 8(SP)
A45E0010 00B4 LDQ R2, 16(SP)
A47E0018 00B8 LDQ R3, 24(SP)
A49E0020 00BC LDQ R4, 32(SP)
A7BE0028 00C0 LDQ FP, 40(SP)
23DE0030 00C4 LDA SP, 48(SP)
6BFC8001 00C8 RET R28
00CC $L3:
; 000017
44840404 00CC BIS R4, R4, R4
43E40124 00D0 SUBL R31, R4, R4
C3FFFFF0 00D4 BR 3_300$
; 000018
00D8 $L4:
; 000006
2F400001 00D8 LDQ_U R26, 1(R0)
4B400B5C 00DC EXTWH R26, R0, R28
445C0402 00E0 BIS R2, R28, R2
C3FFFFD4 00E4 BR $L5

with /OPT:

.PSECT $CODE, QUAD, PIC, CON, REL,
LCL, SHR, EXE, RD, NOWRT
0000 STR_INT_VAL::
23DEFFD0 0000 LDA SP, -48(SP)
B77E0000 0004 STQ R27, (SP)
B75E0008 0008 STQ R26, 8(SP)
B45E0010 000C STQ R2, 16(SP)
B47E0018 0010 STQ R3, 24(SP)
B49E0020 0014 STQ R4, 32(SP)
B7BE0028 0018 STQ FP, 40(SP)
47FE041D 001C MOV SP, FP
0020 $L1:
43F00000 0020 SEXTL R16, R0
; 000004
2C400000 0024 LDQ_U R2, (R0)
; 000006
A0200004 0028 LDL R1, 4(R0)
; 000005
485002C2 002C EXTWL R2, R16, R2
; 000006
F200002F 0030 BLBS R16, $L4
0034 $L5:
47FF0400 0034 CLR R0
; 000007
47FF0403 0038 CLR R3
; 000010
47E03404 003C MOV 1, R4
; 000011
EC40001B 0040 BLE R2, 3_400$
; 000009
2FFE0000 0044 UNOP
2FFE0000 0048 UNOP
2FFE0000 004C UNOP
0050 3_100$:
; 000012
2F010000 0050 LDQ_U R24, (R1)
447FF103 0054 BIC R3, 255, R3
4B0100D8 0058 EXTBL R24, R1, R24
44780403 005C BIS R3, R24, R3
447FF016 0060 AND R3, 255, R22
; 000013
2256FFE0 0064 LDA R18, -32(R22)
E640000D 0068 BEQ R18, 3_300$
; 000014
447FF01A 006C AND R3, 255, R26
; 000015
225AFFD3 0070 LDA R18, -45(R26)
E640001A 0074 BEQ R18, $L3
; 000016
0078 3_200$:
; 000019
40661139 0078 SUBL R3, 48, R25
473FF019 007C AND R25, 255, R25
447FF103 0080 BIC R3, 255, R3
40000000 0084 ADDL R0, R0, R0
; 000020
44790403 0088 BIS R3, R25, R3
; 000019
40000040 008C S4ADDL R0, R0, R0
; 000020
40600000 0090 ADDL R3, R0, R0
; 000021
2FFE0000 0094 UNOP
2FFE0000 0098 UNOP
2FFE0000 009C UNOP
00A0 3_300$:
; 000022
40403122 00A0 SUBL R2, 1, R2
; 000023
40203001 00A4 ADDL R1, 1, R1
; 000022
FC5FFFE9 00A8 BGT R2, 3_100$
; 000025
4C040000 00AC MULL R0, R4, R0
; 000026
00B0 3_400$:
; 000027
B0110000 00B0 STL R0, (R17)
00B4 $L2:
; 000028
47FD041E 00B4 MOV FP, SP
A79D0008 00B8 LDQ R28, 8(FP)
A45D0010 00BC LDQ R2, 16(FP)
A47D0018 00C0 LDQ R3, 24(FP)
A49D0020 00C4 LDQ R4, 32(FP)
A7BD0028 00C8 LDQ FP, 40(FP)
23DE0030 00CC LDA SP, 48(SP)
6BFC8001 00D0 RET R28
2FFE0000 00D4 UNOP
2FFE0000 00D8 UNOP
2FFE0000 00DC UNOP
00E0 $L3:
; 000017
43E40124 00E0 SUBL R31, R4, R4
C3FFFFEE 00E4 BR 3_300$
; 000018
2FFE0000 00E8 UNOP
2FFE0000 00EC UNOP
00F0 $L4:
; 000006
2F400001 00F0 LDQ_U R26, 1(R0)
4B400B5C 00F4 EXTWH R26, R0, R28
445C0402 00F8 BIS R2, R28, R2
C3FFFFCD 00FC BR $L5

On 2023-07-25, Chris Townley <news@cct-net.co.uk> wrote:
>
> Never used macro32 - I gave up any low level language after playing with
> Zilog Z80 code in the early 80s
>

Of all the assembly languages I have used (PDP-11, VAX, Alpha, x86, MIPS,
ARM, Z80, 8-bit PIC, plus various historical others), I found traditional
full ARM to be by far the nicest and 8-bit PIC was easily the most ugly.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Den 2023-07-26 kl. 14:14, skrev Simon Clubley:
> On 2023-07-25, Chris Townley <news@cct-net.co.uk> wrote:
>>
>> Never used macro32 - I gave up any low level language after playing with
>> Zilog Z80 code in the early 80s
>>
>
> Of all the assembly languages I have used (PDP-11, VAX, Alpha, x86, MIPS,
> ARM, Z80, 8-bit PIC, plus various historical others), I found traditional
> full ARM to be by far the nicest and 8-bit PIC was easily the most ugly.
>
> Simon.
>

"8-bit PIC" can mean 2-3 different architectures and instruction sets.
Later PIC16xxxx has a much nicer architecture then the older PIC16's.
And ay more concistent and cleaner then, as an example, AVR...

On 7/26/2023 8:14 AM, Simon Clubley wrote:
> On 2023-07-25, Chris Townley <news@cct-net.co.uk> wrote:
>>
>> Never used macro32 - I gave up any low level language after playing with
>> Zilog Z80 code in the early 80s
>>
>
> Of all the assembly languages I have used (PDP-11, VAX, Alpha, x86, MIPS,
> ARM, Z80, 8-bit PIC, plus various historical others), I found traditional
> full ARM to be by far the nicest and 8-bit PIC was easily the most ugly.
>
> Simon.
>

It's been a very long time ago, but I sort of liked Macro-10.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 2023-07-26, Dave Froble <davef@tsoft-inc.com> wrote:
> On 7/26/2023 8:14 AM, Simon Clubley wrote:
>> On 2023-07-25, Chris Townley <news@cct-net.co.uk> wrote:
>>>
>>> Never used macro32 - I gave up any low level language after playing with
>>> Zilog Z80 code in the early 80s
>>>
>>
>> Of all the assembly languages I have used (PDP-11, VAX, Alpha, x86, MIPS,
>> ARM, Z80, 8-bit PIC, plus various historical others), I found traditional
>> full ARM to be by far the nicest and 8-bit PIC was easily the most ugly.
>>
>
> It's been a very long time ago, but I sort of liked Macro-10.
>

Unfortunately, that's _way_ before my time... :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> On 2023-07-26, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 7/26/2023 8:14 AM, Simon Clubley wrote:
>>> On 2023-07-25, Chris Townley <news@cct-net.co.uk> wrote:

>>>> Never used macro32 - I gave up any low level language after playing with
>>>> Zilog Z80 code in the early 80s

>>> Of all the assembly languages I have used (PDP-11, VAX, Alpha, x86, MIPS,
>>> ARM, Z80, 8-bit PIC, plus various historical others), I found traditional
>>> full ARM to be by far the nicest and 8-bit PIC was easily the most ugly.

>> It's been a very long time ago, but I sort of liked Macro-10.

> Unfortunately, that's _way_ before my time... :-)

Ha! I still make a living programming in Macro-{10,20}, because certain tools
are written in it and nothing else will do.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On 7/26/2023 8:14 AM, Simon Clubley wrote:
> On 2023-07-25, Chris Townley <news@cct-net.co.uk> wrote:
>> Never used macro32 - I gave up any low level language after playing with
>> Zilog Z80 code in the early 80s
>
> Of all the assembly languages I have used (PDP-11, VAX, Alpha, x86, MIPS,
> ARM, Z80, 8-bit PIC, plus various historical others), I found traditional
> full ARM to be by far the nicest and 8-bit PIC was easily the most ugly.

"nicest" in what way?

Traditionally VAX and M68K has been considered the most high level
and requiring least lines of code per functionality.

But there can be many definitions of nice.

Arne

=?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> wrote:
>On 7/26/2023 8:14 AM, Simon Clubley wrote:
>> On 2023-07-25, Chris Townley <news@cct-net.co.uk> wrote:
>>> Never used macro32 - I gave up any low level language after playing with
>>> Zilog Z80 code in the early 80s
>>
>> Of all the assembly languages I have used (PDP-11, VAX, Alpha, x86, MIPS,
>> ARM, Z80, 8-bit PIC, plus various historical others), I found traditional
>> full ARM to be by far the nicest and 8-bit PIC was easily the most ugly.
>
>"nicest" in what way?

I think the ARM is nicest in terms of being able to know what to do without
having to know strange details about inconsistent instructions. You can do
any operation in any mode on any register. The Z-80 is not like that.
I spend all my time thinking about whether I can use the index register for
that or if I have to move the index register into BC first. It is not nice.

>Traditionally VAX and M68K has been considered the most high level
>and requiring least lines of code per functionality.

The Vax is full of all kinds of very cool instructions and if you know
all the details about all of them you can do some fine things. But I
remember once doing a sequence of multiply and add instruction and then
realizing I could use polyd for that and then wondering if it would actually
be faster or slower to use polyd on our machine. I looked up in the book
and toted up cycles and I am not sure I ever did decide. I wound up just
leaving it the way it was.

It's possible to do some pretty amazing things... I remember seeing the
output of a compiler on the Cyber 750 that used the floating point normalize
instruction to move characters around. It was very ingenious but it was
not nice.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 26/07/2023 20:18, Arne Vajhøj wrote:
> On 7/26/2023 8:14 AM, Simon Clubley wrote:
>> On 2023-07-25, Chris Townley <news@cct-net.co.uk> wrote:
>>> Never used macro32 - I gave up any low level language after playing with
>>> Zilog Z80 code in the early 80s
>>
>> Of all the assembly languages I have used (PDP-11, VAX, Alpha, x86, MIPS,
>> ARM, Z80, 8-bit PIC, plus various historical others), I found traditional
>> full ARM to be by far the nicest and 8-bit PIC was easily the most ugly.
>
> "nicest" in what way?
>
> Traditionally VAX and M68K has been considered the most high level
> and requiring least lines of code per functionality.
>
> But there can be many definitions of nice.
>
> Arne >

I like the biscuits ;)

--
Chris

On Wednesday, July 26, 2023 at 2:54:07 PM UTC-7, Scott Dorsey wrote:

(snip)

> The Vax is full of all kinds of very cool instructions and if you know
> all the details about all of them you can do some fine things. But I
> remember once doing a sequence of multiply and add instruction and then
> realizing I could use polyd for that and then wondering if it would actually
> be faster or slower to use polyd on our machine. I looked up in the book
> and toted up cycles and I am not sure I ever did decide. I wound up just
> leaving it the way it was.

I remember stories back to when VAX was new, so 11/780 days,
the POLYD was slower than separate multiply/add instructions.

I never looked at actual times, and don't know at all for later processors.

On 7/26/2023 2:33 PM, Rich Alderson wrote:
> Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>
>> On 2023-07-26, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 7/26/2023 8:14 AM, Simon Clubley wrote:
>>>> On 2023-07-25, Chris Townley <news@cct-net.co.uk> wrote:
>
>>>>> Never used macro32 - I gave up any low level language after playing with
>>>>> Zilog Z80 code in the early 80s
>
>>>> Of all the assembly languages I have used (PDP-11, VAX, Alpha, x86, MIPS,
>>>> ARM, Z80, 8-bit PIC, plus various historical others), I found traditional
>>>> full ARM to be by far the nicest and 8-bit PIC was easily the most ugly.
>
>>> It's been a very long time ago, but I sort of liked Macro-10.
>
>> Unfortunately, that's _way_ before my time... :-)
>
> Ha! I still make a living programming in Macro-{10,20}, because certain tools
> are written in it and nothing else will do.
>

Wait a minute. Are you saying you still make a living supporting
SYSTEM-10 and SYSTEM-20 computers and not just hobbyist machines?

Brings up yet another question, I guess.

I have always wondered why they created the VAX instead of continuing
development of the PDP-11. I mean, look what INTEL did taking the 8080
(or maybe even the 8008) all the way to x86-64.

But now I have to wonder why they didn't just continue development of
the 10 and 20.

bill

On 2023-07-26 21:18, Arne Vajhøj wrote:
> On 7/26/2023 8:14 AM, Simon Clubley wrote:
>> On 2023-07-25, Chris Townley <news@cct-net.co.uk> wrote:
>>> Never used macro32 - I gave up any low level language after playing with
>>> Zilog Z80 code in the early 80s
>>
>> Of all the assembly languages I have used (PDP-11, VAX, Alpha, x86, MIPS,
>> ARM, Z80, 8-bit PIC, plus various historical others), I found traditional
>> full ARM to be by far the nicest and 8-bit PIC was easily the most ugly.
>
> "nicest" in what way?
>
> Traditionally VAX and M68K has been considered the most high level
> and requiring least lines of code per functionality.
>
> But there can be many definitions of nice.

This is so subjective that I didn't even think it was worth commenting...

Johnny

On Wednesday, July 26, 2023 at 6:48:05 PM UTC-4, gah4 wrote:
> I remember stories back to when VAX was new, so 11/780 days,
> the POLYD was slower than separate multiply/add instructions.
>
> I never looked at actual times, and don't know at all for later processors.

There was also the case of the backup program being sped up by replacing
the CRC instruction with a routine coded with simpler instructions. This
improvement affected a lot a shops.

On Wednesday, July 26, 2023 at 5:05:41 PM UTC-7, bill wrote:
(snip)

> I have always wondered why they created the VAX instead of continuing
> development of the PDP-11. I mean, look what INTEL did taking the 8080
> (or maybe even the 8008) all the way to x86-64.

But VAX is the 32 bit extension of the PDP-11. That is why they have
numbers like 11/780. Some models have PDP-11 comparability (sic)
mode to run PDP-11 software.

> But now I have to wonder why they didn't just continue development of
> the 10 and 20.
Partly, the world was moving to 8 bit byte addressable systems.
Or at least an 8 bit character set.

But yes, it seems that many wondered that at the time.

On 7/26/2023 8:05 PM, bill wrote:

> But now I have to wonder why they didn't just continue development of
> the 10 and 20.

Ah, Jupiter . . .

--

--- Rob

In article <1389dbdd-5e45-4688-a8ae-ff36de25ee78n@googlegroups.com>,
gah4@u.washington.edu (gah4) wrote:
> On Wednesday, July 26, 2023 at 5:05:41_PM UTC-7, bill wrote:
> > But now I have to wonder why they didn't just continue
> > development of the 10 and 20.

> Partly, the world was moving to 8 bit byte addressable systems.
> Or at least an 8 bit character set.
>
> But yes, it seems that many wondered that at the time.

It looks like a commercial decision. As of 1982-83, when the decision was
being made, VAX was wildly successful, and DEC-10 and DEC-20 were not
growing fast.

John

On 2023-07-26, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 7/26/2023 8:14 AM, Simon Clubley wrote:
>> On 2023-07-25, Chris Townley <news@cct-net.co.uk> wrote:
>>> Never used macro32 - I gave up any low level language after playing with
>>> Zilog Z80 code in the early 80s
>>
>> Of all the assembly languages I have used (PDP-11, VAX, Alpha, x86, MIPS,
>> ARM, Z80, 8-bit PIC, plus various historical others), I found traditional
>> full ARM to be by far the nicest and 8-bit PIC was easily the most ugly.
>
> "nicest" in what way?
>

As Scott points out the traditional ARM architecture is very elegant.

> Traditionally VAX and M68K has been considered the most high level
> and requiring least lines of code per functionality.
>

M68K I can't talk about because I never used it. That's why I limited
my comment above to the assembly languages I do know.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-07-27 02:05, bill wrote:
> On 7/26/2023 2:33 PM, Rich Alderson wrote:

>> Ha!  I still make a living programming in Macro-{10,20}, because
>> certain tools
>> are written in it and nothing else will do.
>>
>
> Wait a minute.  Are you saying you still make a living supporting
> SYSTEM-10 and SYSTEM-20 computers and not just hobbyist machines?
>
> Brings up  yet another question, I guess.
>
> I have always wondered why they created the VAX instead of continuing
> development of the PDP-11. I mean, look what INTEL did taking the 8080
> (or maybe even the 8008) all the way to x86-64.

You could argue that this is what DEC did. Except they eventually
dropped PDP-11 support in hardware and moved it to software emulation,
and then dropped it altogether. Which just suggest they didn't think
there was enough value to keep it around.
And doing explicitly as a compatibility mode allowed for a cleaner
design than what Intel did with the 8080.
I assume you haven't missed all the cursing of that architecture.

> But now I have to wonder why they didn't just continue development of
> the 10 and 20.

Do you really want to open up that wound again? :-D

Johnny

Den 2023-07-27 kl. 14:46, skrev Johnny Billquist:
> On 2023-07-27 02:05, bill wrote:
>> On 7/26/2023 2:33 PM, Rich Alderson wrote:
>
>>> Ha!  I still make a living programming in Macro-{10,20}, because certain
>>> tools
>>> are written in it and nothing else will do.
>>>
>>
>> Wait a minute.  Are you saying you still make a living supporting
>> SYSTEM-10 and SYSTEM-20 computers and not just hobbyist machines?
>>
>> Brings up  yet another question, I guess.
>>
>> I have always wondered why they created the VAX instead of continuing
>> development of the PDP-11. I mean, look what INTEL did taking the 8080
>> (or maybe even the 8008) all the way to x86-64.
>
> You could argue that this is what DEC did. Except they eventually dropped
> PDP-11 support in hardware and moved it to software emulation, and then
> dropped it altogether. Which just suggest they didn't think there was
> enough value to keep it around.

PDP-11 software that was run within the VAX hardware environment was
probably just moved to the VAX/VMS platform.

Software that needed the PDP-11 platform (maybe due to special
interfaces and I/O cards) probably stayed on real PDP-11 hardware.
I'm sure there was many real PDP-11 systems alive well after that
the PDP-11 emulation in VAX was removed.

> And doing explicitly as a compatibility mode allowed for a cleaner design
> than what Intel did with the 8080.
> I assume you haven't missed all the cursing of that architecture.
>
>> But now I have to wonder why they didn't just continue development of
>> the 10 and 20.
>
> Do you really want to open up that wound again? :-D
>
>   Johnny
>

On 7/27/2023 8:46 AM, Johnny Billquist wrote:
> On 2023-07-27 02:05, bill wrote:
>> On 7/26/2023 2:33 PM, Rich Alderson wrote:
>
>>> Ha!  I still make a living programming in Macro-{10,20}, because
>>> certain tools
>>> are written in it and nothing else will do.
>>>
>>
>> Wait a minute.  Are you saying you still make a living supporting
>> SYSTEM-10 and SYSTEM-20 computers and not just hobbyist machines?
>>
>> Brings up  yet another question, I guess.
>>
>> I have always wondered why they created the VAX instead of continuing
>> development of the PDP-11. I mean, look what INTEL did taking the 8080
>> (or maybe even the 8008) all the way to x86-64.
>
> You could argue that this is what DEC did. Except they eventually
> dropped PDP-11 support in hardware and moved it to software emulation,

Sorry, I certainly don't see it that way. I see nothing in the VAX that
reminds me of the PDP-11.

> and then dropped it altogether. Which just suggest they didn't think
> there was enough value to keep it around.
> And doing explicitly as a compatibility mode allowed for a cleaner
> design than what Intel did with the 8080.
> I assume you haven't missed all the cursing of that architecture.

I worked with 8080's and Z80's (yes, I know that's not Intel). They
were just fine. Unlike the 6502 which I thought was a piece of crap.

>
>> But now I have to wonder why they didn't just continue development of
>> the 10 and 20.
>
> Do you really want to open up that wound again? :-D

I would love to see what the performance would be for any of these
processors made with today's tech. I think even without growing
memory size they would be more than adequate and probably a lot
better than some of the Windows Servers running applications today.

bill

In article <kifmjpF4bvU2@mid.individual.net>, bill.gunshannon@gmail.com
(bill) wrote:

> I would love to see what the performance would be for any of these
> processors [DEC-10, DEC-20] made with today's tech. I think even
> without growing memory size they would be more than adequate and
> probably a lot better than some of the Windows Servers running
> applications today.

What sort of thing would you want to use them for? I don't know the
architecture well, but they seem to be limited to 30-bit addressing of
their 36-bit words. That's more or less 4GB, which will do for many
things, but there doesn't seem to be any obvious advantage of the
architecture that would make doing an commercial implementation
worthwhile.

If you were keen, you could do an FPGA version: some Amiga fans have done
that for the Motorola 68000 family. http://www.apollo-core.com/

The painful part is the character size: 6-bit characters aren't adequate
for lots of modern work. Using 8-bit characters is probably best. That
wastes four bits per word, but allows you to use UTF-8 and communicate
with other kinds of machine.

John