Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.raspberry-pi > #16591 > unrolled thread

Re: Compile Assembly and C files together

Back to article view | Back to comp.sys.raspberry-pi

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Compile Assembly and C files together "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-06 19:20 +0800
    Re: Compile Assembly and C files together jack4747@gmail.com - 2018-03-06 05:12 -0800
    Re: Compile Assembly and C files together druck <news@druck.org.uk> - 2018-03-06 13:53 +0000
      Re: Compile Assembly and C files together Rob Morley <nospam@ntlworld.com> - 2018-03-06 14:59 +0000
        Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-06 16:35 +0100
      Re: Compile Assembly and C files together "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-06 23:01 +0800
    Re: Compile Assembly and C files together ray carter <ray@zianet.com> - 2018-03-06 15:44 +0000
      Re: Compile Assembly and C files together "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-07 00:07 +0800
        Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-07 22:39 +0200
          Re: Compile Assembly and C files together "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-08 18:18 +0800
            Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-08 12:37 +0000
              Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-08 13:13 +0000
                Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-08 13:34 +0000
                  Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-08 15:27 +0000
                    Re: Compile Assembly and C files together mm0fmf <none@invalid.com> - 2018-03-08 17:33 +0000
                      Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 09:06 +0000
                        Re: Compile Assembly and C files together Richard Kettlewell <invalid@invalid.invalid> - 2018-03-09 09:17 +0000
                          Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 09:30 +0000
                            Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 15:56 +0200
                              Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-09 14:13 +0000
                                Re: Compile Assembly and C files together Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2018-03-09 11:14 -0500
                                  Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 17:44 +0000
                                Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-09 17:16 +0100
                                  Re: Compile Assembly and C files together Robert Wessel <robertwessel2@yahoo.com> - 2018-03-09 11:19 -0600
                                    Re: Compile Assembly and C files together bartc <bc@freeuk.com> - 2018-03-09 18:11 +0000
                                      Re: Compile Assembly and C files together Robert Wessel <robertwessel2@yahoo.com> - 2018-03-09 13:41 -0600
                                    Re: Compile Assembly and C files together David Brown <david.brown@hesbynett.no> - 2018-03-09 19:20 +0100
                                      Re: Compile Assembly and C files together Robert Wessel <robertwessel2@yahoo.com> - 2018-03-09 13:48 -0600
                                  Re: Compile Assembly and C files together Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2018-03-09 13:16 -0500
                                    Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-09 18:29 +0000
                                      Re: Compile Assembly and C files together Jack Fearnley <jack@alcor.concordia.ca> - 2018-03-09 19:07 +0000
                                        Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-09 19:13 +0000
                                          Re: Compile Assembly and C files together Michael J. Mahon <mjmahon@aol.com> - 2018-03-10 13:16 -0600
                                            Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-11 19:39 +0000
                                              Re: Compile Assembly and C files together Michael J. Mahon <mjmahon@aol.com> - 2018-03-12 01:16 -0500
                                                Re: Compile Assembly and C files together David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2018-03-12 06:39 +0000
                                                Re: Compile Assembly and C files together Martin Gregorie <martin@mydomain.invalid> - 2018-03-12 20:49 +0000
                                              Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 16:11 +0000
                                                Re: Compile Assembly and C files together Michael J. Mahon <mjmahon@aol.com> - 2018-03-12 14:58 -0500
                                                  Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 20:38 +0000
                                            Re: Compile Assembly and C files together scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 16:06 +0000
                                              Re: Compile Assembly and C files together Michael J. Mahon <mjmahon@aol.com> - 2018-03-12 14:58 -0500
                                    Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 21:27 +0200
                              Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 17:40 +0000
                                Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 21:30 +0200
                              Re: Compile Assembly and C files together Richard Damon <Richard@Damon-Family.org> - 2018-03-09 13:16 -0500
                                Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 21:33 +0200
                        Re: Compile Assembly and C files together mm0fmf <none@invalid.com> - 2018-03-09 17:40 +0000
                          Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 17:47 +0000
                            Re: Compile Assembly and C files together mm0fmf <none@invalid.com> - 2018-03-09 18:05 +0000
                      Compile Assembly and C files together nospam.mark.lewis@p73.f12.n3634.z1.binkp.net (mark lewis) - 2018-03-09 04:17 +1200
                    Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-09 09:05 +0000
                      Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-09 16:01 +0200
              Re: Compile Assembly and C files together jack4747@gmail.com - 2018-03-08 05:46 -0800
                Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-08 14:47 +0000
            Re: Compile Assembly and C files together Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2018-03-08 17:25 +0200
    Re: Compile Assembly and C files together The Natural Philosopher <tnp@invalid.invalid> - 2018-03-07 07:36 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#16628

On Fri, 9 Mar 2018 14:13:40 +0000, bartc <bc@freeuk.com> declaimed the
following:


>
>Somewhat tidier than that for x64, which varies between Windows and 
>Linux. Windows has the simpler one, and passes the first four arguments 
>in rcx, rdx, r8 and r9.
>
>So not only are the registers not consecutive, but they couldn't even 
>come up with a consistent naming scheme for the registers.
>

	CX and DX are likely historical carry-overs from the 8008/8080 (A, C,
D, H, L, with an X to indicate a wide register).


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/ 

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

#16634

On 09/03/18 16:14, Dennis Lee Bieber wrote:
> On Fri, 9 Mar 2018 14:13:40 +0000, bartc <bc@freeuk.com> declaimed the
> following:
> 
> 
>>
>> Somewhat tidier than that for x64, which varies between Windows and
>> Linux. Windows has the simpler one, and passes the first four arguments
>> in rcx, rdx, r8 and r9.
>>
>> So not only are the registers not consecutive, but they couldn't even
>> come up with a consistent naming scheme for the registers.
>>
> 
> 	CX and DX are likely historical carry-overs from the 8008/8080 (A, C,
> D, H, L, with an X to indicate a wide register).
> 
> 
Nack when I was writing assemble fr 8086, There wer AX, BX, CX, abd DX.

AX was the accumulator and ewas used as a return register.

There were more registers intended  to be used as memory pointers, but 
not one of the compilers I used then passed parameters except on the stack.

Indeed I am not sure that early versions of gcc did either.



-- 
“it should be clear by now to everyone that activist environmentalism 
(or environmental activism) is becoming a general ideology about humans, 
about their freedom, about the relationship between the individual and 
the state, and about the manipulation of people under the guise of a 
'noble' idea. It is not an honest pursuit of 'sustainable development,' 
a matter of elementary environmental protection, or a search for 
rational mechanisms designed to achieve a healthy environment. Yet 
things do occur that make you shake your head and remind yourself that 
you live neither in Joseph Stalin’s Communist era, nor in the Orwellian 
utopia of 1984.”

Vaclav Klaus

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

#16629

On 09/03/18 15:13, bartc wrote:
> On 09/03/2018 13:56, Tauno Voipio wrote:
>> On 9.3.18 11:30, The Natural Philosopher wrote:
> 
>>> Even so, the method still reveals WHICH registers
>>>
>>> But it is not a feature of the ARM per se, merely a convention.
>>>
>>> I assume gcc follows it, but there is no gurantee
>>
>> GCC follows the ARM EABI specification:
>>
>>   - stack on 8 byte boundaries,
>>   - arguments in r0 - r3
>>   - return value in r0
> 
> 
> Somewhat tidier than that for x64, which varies between Windows and
> Linux.

Or rather, varies between Windows and everything else.  (There are other
OS's out there.)

> Windows has the simpler one, and passes the first four arguments
> in rcx, rdx, r8 and r9.

<https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions>

I don't know quite why you think Windows has a simpler calling
convention here - it uses fewer registers for parameter passing, but has
this bizarre "shadow space" that the caller must allocate before calling
functions.  And MS, having failed to learn from its previous dog's
breakfast on 32-bit Windows, has two different calling conventions.
Still, it is simpler than the five different conventions on Win32.

> 
> So not only are the registers not consecutive, but they couldn't even
> come up with a consistent naming scheme for the registers.
> 

Having the registers consecutive would not make much difference.  It
might be useful on some platforms when using variadic functions if the
compiler could use a "push multiple registers" instruction.

Consistent naming would be nice, I agree.

> /And/ the stack has to be kept at 16-byte alignment, even though
> individual parameters (the ones that have to go on the stack, and shadow
> space for the first four), are all 8 bytes each. That is, it needs to be
> 16-byte aligned just before you execute 'call'.

There are good reasons for having a 16-byte stack alignment.  The
primary ones are to improve cache line alignment, and because some SIMD
instructions require larger alignment.

> 
> Keeping track of that is a nightmare, and a real problem when writing
> extensive ASM code that has to make calls to conforming functions.
> 

That's part of the fun of writing assembly code, isn't it?  The other
view is that it is a good reason for programming in C instead of assembly.

> Further (I don't know if this applies to ARM; does it have a separate
> set of floating point registers?), floating point params need to be
> passed in a corresponding floating point register instead, XMM0 to XMM3
> (here, the names /are/ consistent, and they are consecutive!). For
> variadic floating point arguments, they need to be passed in both.
> 
> Phew! And that's the easier Win64 ABI.
> 
> I guess simplicity of the call convention wasn't a priority.
> 

Well no, of course it was not a priority.  Why should it be?  Virtually
no one is interested in the calling conventions - just compiler writers,
people writing OS context switch routines, and the few dozen people
writing assembly routines instead of using higher level languages.
Efficiency of generated code was far and away the priority when AMD made
the System V AMD64 ABI used by everyone except Windows.  $DEITY only
knows what MS's priorities were when they scrambled it and made
something pointlessly different and less efficient - the only think I
can think of was to make implementation of "printf" a little easier for
the MSVC compiler writers.

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

#16631

On Fri, 09 Mar 2018 17:16:19 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>On 09/03/18 15:13, bartc wrote:
>> On 09/03/2018 13:56, Tauno Voipio wrote:
>>> On 9.3.18 11:30, The Natural Philosopher wrote:
>> 
>>>> Even so, the method still reveals WHICH registers
>>>>
>>>> But it is not a feature of the ARM per se, merely a convention.
>>>>
>>>> I assume gcc follows it, but there is no gurantee
>>>
>>> GCC follows the ARM EABI specification:
>>>
>>>   - stack on 8 byte boundaries,
>>>   - arguments in r0 - r3
>>>   - return value in r0
>> 
>> 
>> Somewhat tidier than that for x64, which varies between Windows and
>> Linux.
>
>Or rather, varies between Windows and everything else.  (There are other
>OS's out there.)
>
>> Windows has the simpler one, and passes the first four arguments
>> in rcx, rdx, r8 and r9.
>
><https://en.wikipedia.org/wiki/X86_calling_conventions#x86-64_calling_conventions>
>
>I don't know quite why you think Windows has a simpler calling
>convention here - it uses fewer registers for parameter passing, but has
>this bizarre "shadow space" that the caller must allocate before calling
>functions.  And MS, having failed to learn from its previous dog's
>breakfast on 32-bit Windows, has two different calling conventions.
>Still, it is simpler than the five different conventions on Win32.
>
>> 
>> So not only are the registers not consecutive, but they couldn't even
>> come up with a consistent naming scheme for the registers.
>> 
>
>Having the registers consecutive would not make much difference.  It
>might be useful on some platforms when using variadic functions if the
>compiler could use a "push multiple registers" instruction.
>
>Consistent naming would be nice, I agree.


Although that's hardly MS's fault.


>> /And/ the stack has to be kept at 16-byte alignment, even though
>> individual parameters (the ones that have to go on the stack, and shadow
>> space for the first four), are all 8 bytes each. That is, it needs to be
>> 16-byte aligned just before you execute 'call'.
>
>There are good reasons for having a 16-byte stack alignment.  The
>primary ones are to improve cache line alignment, and because some SIMD
>instructions require larger alignment.
>
>> 
>> Keeping track of that is a nightmare, and a real problem when writing
>> extensive ASM code that has to make calls to conforming functions.
>> 
>
>That's part of the fun of writing assembly code, isn't it?  The other
>view is that it is a good reason for programming in C instead of assembly.
>
>> Further (I don't know if this applies to ARM; does it have a separate
>> set of floating point registers?), floating point params need to be
>> passed in a corresponding floating point register instead, XMM0 to XMM3
>> (here, the names /are/ consistent, and they are consecutive!). For
>> variadic floating point arguments, they need to be passed in both.
>> 
>> Phew! And that's the easier Win64 ABI.
>> 
>> I guess simplicity of the call convention wasn't a priority.
>> 
>
>Well no, of course it was not a priority.  Why should it be?  Virtually
>no one is interested in the calling conventions - just compiler writers,
>people writing OS context switch routines, and the few dozen people
>writing assembly routines instead of using higher level languages.
>Efficiency of generated code was far and away the priority when AMD made
>the System V AMD64 ABI used by everyone except Windows.  $DEITY only
>knows what MS's priorities were when they scrambled it and made
>something pointlessly different and less efficient - the only think I
>can think of was to make implementation of "printf" a little easier for
>the MSVC compiler writers.


While I'm not going to try to defend it, MS's explanation is that
there's no cost to actually allocate the spill space (just a change to
the stack adjustment done at entry to the calling function, and the
space is not usually wasted (and thus does not impact caching),
compilers can use it for local variables if they're not going to spill
the first four parameters to that space.  And it does, of course, make
the variadic parameter thing easier.

https://blogs.msdn.microsoft.com/oldnewthing/20160623-00/?p=93735

I'm not aware of any good benchmarks comparing the more common
convention and MS's, but if it's actually an issue, it's probable that
the entire function call should be eliminated by some form of inlining
instead.  Admittedly there are places where many function calls are
required, but most of the time it's just people computing Fibonacci
numbers or the Ackerman function in poorly thought out benchmarks.

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

#16637

On 09/03/2018 17:19, Robert Wessel wrote:
> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown
> <david.brown@hesbynett.no> wrote:

>> Consistent naming would be nice, I agree.
> 
> 
> Although that's hardly MS's fault.

It's probably AMD's. (In my assembler, I support both standard register 
names, and also my own versions which are consecutive /and/ consistent. 
Win64 ABI parameters are passed in 'D10' to 'D13'. D0 to D9 are general 
purpose. D14/D15 are the frame and stack pointers.)

> I'm not aware of any good benchmarks comparing the more common
> convention and MS's, but if it's actually an issue, it's probable that
> the entire function call should be eliminated by some form of inlining
> instead.  Admittedly there are places where many function calls are
> required, but most of the time it's just people computing Fibonacci
> numbers or the Ackerman function in poorly thought out benchmarks.
> 

I have a non-C compiler for x64 than can generate either simple 
stack-based calls, or full Win64 ABI.

When applied to an interpreter, the full ABI gives a slow-down of 25-35% 
when running code, in one case up to 60%. (With the interpreter running 
a loop calling via function pointers, whatever the target app.)

With other apps, the differences are much narrower.

This is a non-optimising compiler, and the ABI code could do with some 
tidying up, but it shows using the official ABI requires more effort in 
generating efficient code.

-- 
bartc

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

#16648

On Fri, 9 Mar 2018 18:11:15 +0000, bartc <bc@freeuk.com> wrote:

>On 09/03/2018 17:19, Robert Wessel wrote:
>> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown

>
>> I'm not aware of any good benchmarks comparing the more common
>> convention and MS's, but if it's actually an issue, it's probable that
>> the entire function call should be eliminated by some form of inlining
>> instead.  Admittedly there are places where many function calls are
>> required, but most of the time it's just people computing Fibonacci
>> numbers or the Ackerman function in poorly thought out benchmarks.
>> 
>
>I have a non-C compiler for x64 than can generate either simple 
>stack-based calls, or full Win64 ABI.
>
>When applied to an interpreter, the full ABI gives a slow-down of 25-35% 
>when running code, in one case up to 60%. (With the interpreter running 
>a loop calling via function pointers, whatever the target app.)
>
>With other apps, the differences are much narrower.
>
>This is a non-optimising compiler, and the ABI code could do with some 
>tidying up, but it shows using the official ABI requires more effort in 
>generating efficient code.


The point of comparison was the MS/Windows calling convention vs. the
more common one used by *nix (and others).  Compilers have a very long
history of using non-standard calling conventions internally.

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

#16640

On 09/03/18 18:19, Robert Wessel wrote:
> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 09/03/18 15:13, bartc wrote:

<snip>

>> Consistent naming would be nice, I agree.
> 
> 
> Although that's hardly MS's fault.

No - it is "for historical reasons".

> 
> 
>>> /And/ the stack has to be kept at 16-byte alignment, even though
>>> individual parameters (the ones that have to go on the stack, and shadow
>>> space for the first four), are all 8 bytes each. That is, it needs to be
>>> 16-byte aligned just before you execute 'call'.
>>
>> There are good reasons for having a 16-byte stack alignment.  The
>> primary ones are to improve cache line alignment, and because some SIMD
>> instructions require larger alignment.
>>
>>>
>>> Keeping track of that is a nightmare, and a real problem when writing
>>> extensive ASM code that has to make calls to conforming functions.
>>>
>>
>> That's part of the fun of writing assembly code, isn't it?  The other
>> view is that it is a good reason for programming in C instead of assembly.
>>
>>> Further (I don't know if this applies to ARM; does it have a separate
>>> set of floating point registers?), floating point params need to be
>>> passed in a corresponding floating point register instead, XMM0 to XMM3
>>> (here, the names /are/ consistent, and they are consecutive!). For
>>> variadic floating point arguments, they need to be passed in both.
>>>
>>> Phew! And that's the easier Win64 ABI.
>>>
>>> I guess simplicity of the call convention wasn't a priority.
>>>
>>
>> Well no, of course it was not a priority.  Why should it be?  Virtually
>> no one is interested in the calling conventions - just compiler writers,
>> people writing OS context switch routines, and the few dozen people
>> writing assembly routines instead of using higher level languages.
>> Efficiency of generated code was far and away the priority when AMD made
>> the System V AMD64 ABI used by everyone except Windows.  $DEITY only
>> knows what MS's priorities were when they scrambled it and made
>> something pointlessly different and less efficient - the only think I
>> can think of was to make implementation of "printf" a little easier for
>> the MSVC compiler writers.
> 
> 
> While I'm not going to try to defend it, MS's explanation is that
> there's no cost to actually allocate the spill space (just a change to
> the stack adjustment done at entry to the calling function, and the
> space is not usually wasted (and thus does not impact caching),
> compilers can use it for local variables if they're not going to spill
> the first four parameters to that space.  And it does, of course, make
> the variadic parameter thing easier.

That is an interesting view on it - thanks.

However, it /will/ have a cost in the case of functions that do not 
otherwise need to allocate space in the stack other than the automatic 
push/pop from the call/ret pair.  So a small function that could 
otherwise be run entirely from within the caller-saved registers, but 
which itself calls another function, will need to allocate stack.  This 
might seem rare, but I am sure it turns up a lot in C++ code with all 
these functions that don't seem to do anything except pass on 
responsibility to other functions!

> 
> https://blogs.msdn.microsoft.com/oldnewthing/20160623-00/?p=93735
> 
> I'm not aware of any good benchmarks comparing the more common
> convention and MS's, but if it's actually an issue, it's probable that
> the entire function call should be eliminated by some form of inlining
> instead.  Admittedly there are places where many function calls are
> required, but most of the time it's just people computing Fibonacci
> numbers or the Ackerman function in poorly thought out benchmarks.
> 

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

#16649

On Fri, 9 Mar 2018 19:20:01 +0100, David Brown
<david.brown@hesbynett.no> wrote:

>On 09/03/18 18:19, Robert Wessel wrote:
>> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown

>>> Well no, of course it was not a priority.  Why should it be?  Virtually
>>> no one is interested in the calling conventions - just compiler writers,
>>> people writing OS context switch routines, and the few dozen people
>>> writing assembly routines instead of using higher level languages.
>>> Efficiency of generated code was far and away the priority when AMD made
>>> the System V AMD64 ABI used by everyone except Windows.  $DEITY only
>>> knows what MS's priorities were when they scrambled it and made
>>> something pointlessly different and less efficient - the only think I
>>> can think of was to make implementation of "printf" a little easier for
>>> the MSVC compiler writers.
>> 
>> 
>> While I'm not going to try to defend it, MS's explanation is that
>> there's no cost to actually allocate the spill space (just a change to
>> the stack adjustment done at entry to the calling function, and the
>> space is not usually wasted (and thus does not impact caching),
>> compilers can use it for local variables if they're not going to spill
>> the first four parameters to that space.  And it does, of course, make
>> the variadic parameter thing easier.
>
>That is an interesting view on it - thanks.
>
>However, it /will/ have a cost in the case of functions that do not 
>otherwise need to allocate space in the stack other than the automatic 
>push/pop from the call/ret pair.  So a small function that could 
>otherwise be run entirely from within the caller-saved registers, but 
>which itself calls another function, will need to allocate stack.  This 
>might seem rare, but I am sure it turns up a lot in C++ code with all 
>these functions that don't seem to do anything except pass on 
>responsibility to other functions!


While true, most of those small C++ functions need to set up a stack
frame anyway so that exception handling can unwind the stack.  That
doesn't, however, change the fact that the shadow area allocation is a
waste of cache space in that scenario.

OTOH, many of those short functions *should* get inlined.  Obviously
that's more difficult if the short functions are virtual ones, but if
you're clunking your way through a indirect call via a vtable anyway,
the added pain from half a wasted cache line is probably modest.

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

#16639

On Fri, 09 Mar 2018 17:16:19 +0100, David Brown <david.brown@hesbynett.no>
declaimed the following:

>On 09/03/18 15:13, bartc wrote:

>> 
>> I guess simplicity of the call convention wasn't a priority.
>> 
>
>Well no, of course it was not a priority.  Why should it be?  Virtually
>no one is interested in the calling conventions - just compiler writers,
>people writing OS context switch routines, and the few dozen people
>writing assembly routines instead of using higher level languages.
>Efficiency of generated code was far and away the priority when AMD made
>the System V AMD64 ABI used by everyone except Windows.  $DEITY only
>knows what MS's priorities were when they scrambled it and made
>something pointlessly different and less efficient - the only think I
>can think of was to make implementation of "printf" a little easier for
>the MSVC compiler writers.

	<HEH>

	There is always the convention used by Xerox Sigma Fortran-IV.
Non-recursive, non-stack...

	Arguments were passed by putting them immediately after the CALL
(branch and link opcode, and referenced by return address (saved in a
register; I think 15 was the standard) + index. Code was responsible for
incrementing the return address to jump over the arguments. {I don't have
my 40 year old manuals handy, so pseudo-ops...}

...
	stw,9	arg2
	bl,15	mysub
	data	arg1	;normally this would save the address of arg1
arg2	data	0	;reserved space for storing a "pass by value"



...

mysub	lw,9	*15	;indirect, load arg1 address into 9
		inc,15
		lw,10	*15	;indirect, load arg2 value into 10
		inc,15
		stw,15	retadd
....
		lw,15	retadd
		ret
retadd	data	0	;space to save return address

	Of course, the pass-by-value semantics would fail for any system that
makes code-space read-only; pass-by-address is a compile time definition.


-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
	wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/ 

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

#16642

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>On Fri, 09 Mar 2018 17:16:19 +0100, David Brown <david.brown@hesbynett.no>
>declaimed the following:

>	<HEH>
>
>	There is always the convention used by Xerox Sigma Fortran-IV.
>Non-recursive, non-stack...
>
>	Arguments were passed by putting them immediately after the CALL
>(branch and link opcode, and referenced by return address (saved in a
>register; I think 15 was the standard) + index.

This was very common in the 1970s.   The PDP-8 had
similar parameter passing as did the Burroughs B2500
and descendents until the early 80's when a re-entrant
call (Virtual Enter (VEN)) was added to the architecture.

Unix system calls (UnixV6 on the PDP-11) embedded the
system call arguments in the instruction stream following
the system call instruction.

The B2500 system call instruction (BCT) had the following
general form:

    BCT NNNN           # NNNN selects the system call
    BUN +Skip          # Branch Unconditional to after the parameters
    ACON label         # first parameter (address constant)
    DATA 2 UN 01       # second parameter, two digit numeric, value 01
.Skip

The operating system would bump the return address by the size
of the branch instruction (8 or 10 digits) to get the parameters.

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

#16643

On Fri, 09 Mar 2018 18:29:25 +0000, Scott Lurndal wrote:

> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>>On Fri, 09 Mar 2018 17:16:19 +0100, David Brown
>><david.brown@hesbynett.no>
>>declaimed the following:
> 
>>	<HEH>
>>
>>	There is always the convention used by Xerox Sigma Fortran-IV.
>>Non-recursive, non-stack...
>>
>>	Arguments were passed by putting them immediately after the CALL
>>(branch and link opcode, and referenced by return address (saved in a
>>register; I think 15 was the standard) + index.
> 
> This was very common in the 1970s.   The PDP-8 had similar parameter
> passing as did the Burroughs B2500 and descendents until the early 80's
> when a re-entrant call (Virtual Enter (VEN)) was added to the
> architecture.
> 
> Unix system calls (UnixV6 on the PDP-11) embedded the system call
> arguments in the instruction stream following the system call
> instruction.
> 
> The B2500 system call instruction (BCT) had the following general form:
> 
>     BCT NNNN           # NNNN selects the system call BUN +Skip         
>     # Branch Unconditional to after the parameters ACON label         #
>     first parameter (address constant)
>     DATA 2 UN 01       # second parameter, two digit numeric, value 01
> .Skip
> 
> The operating system would bump the return address by the size of the
> branch instruction (8 or 10 digits) to get the parameters.

Even further back. This was the standard method in the IBM1401 which I 
was programming in 1960.

Best Regards,
             Jack Fearnley

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

#16644

Jack Fearnley <jack@alcor.concordia.ca> writes:
>On Fri, 09 Mar 2018 18:29:25 +0000, Scott Lurndal wrote:
>
>> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>>>On Fri, 09 Mar 2018 17:16:19 +0100, David Brown
>>><david.brown@hesbynett.no>
>>>declaimed the following:
>> 
>>>	<HEH>
>>>
>>>	There is always the convention used by Xerox Sigma Fortran-IV.
>>>Non-recursive, non-stack...
>>>
>>>	Arguments were passed by putting them immediately after the CALL
>>>(branch and link opcode, and referenced by return address (saved in a
>>>register; I think 15 was the standard) + index.
>> 
>> This was very common in the 1970s.   The PDP-8 had similar parameter
>> passing as did the Burroughs B2500 and descendents until the early 80's
>> when a re-entrant call (Virtual Enter (VEN)) was added to the
>> architecture.
>> 
>> Unix system calls (UnixV6 on the PDP-11) embedded the system call
>> arguments in the instruction stream following the system call
>> instruction.
>> 
>> The B2500 system call instruction (BCT) had the following general form:
>> 
>>     BCT NNNN           # NNNN selects the system call BUN +Skip         
>>     # Branch Unconditional to after the parameters ACON label         #
>>     first parameter (address constant)
>>     DATA 2 UN 01       # second parameter, two digit numeric, value 01
>> .Skip
>> 
>> The operating system would bump the return address by the size of the
>> branch instruction (8 or 10 digits) to get the parameters.
>
>Even further back. This was the standard method in the IBM1401 which I 
>was programming in 1960.

The B2500 dates back to 1965, and it did have a 1401 compability mode :-)

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

#16651

Scott Lurndal <scott@slp53.sl.home> wrote:
> Jack Fearnley <jack@alcor.concordia.ca> writes:
>> On Fri, 09 Mar 2018 18:29:25 +0000, Scott Lurndal wrote:
>> 
>>> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>>>> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown
>>>> <david.brown@hesbynett.no>
>>>> declaimed the following:
>>> 
>>>> <HEH>
>>>> 
>>>> There is always the convention used by Xerox Sigma Fortran-IV.
>>>> Non-recursive, non-stack...
>>>> 
>>>> Arguments were passed by putting them immediately after the CALL
>>>> (branch and link opcode, and referenced by return address (saved in a
>>>> register; I think 15 was the standard) + index.
>>> 
>>> This was very common in the 1970s.   The PDP-8 had similar parameter
>>> passing as did the Burroughs B2500 and descendents until the early 80's
>>> when a re-entrant call (Virtual Enter (VEN)) was added to the
>>> architecture.
>>> 
>>> Unix system calls (UnixV6 on the PDP-11) embedded the system call
>>> arguments in the instruction stream following the system call
>>> instruction.
>>> 
>>> The B2500 system call instruction (BCT) had the following general form:
>>> 
>>> BCT NNNN           # NNNN selects the system call BUN +Skip         
>>> # Branch Unconditional to after the parameters ACON label         #
>>> first parameter (address constant)
>>> DATA 2 UN 01       # second parameter, two digit numeric, value 01
>>> .Skip
>>> 
>>> The operating system would bump the return address by the size of the
>>> branch instruction (8 or 10 digits) to get the parameters.
>> 
>> Even further back. This was the standard method in the IBM1401 which I 
>> was programming in 1960.
> 
> The B2500 dates back to 1965, and it did have a 1401 compability mode :-)
> 

Not a compatibility mode, but a software emulator (which was little used by
1967). 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

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

#16652

On Sat, 10 Mar 2018 13:16:18 -0600, Michael J. Mahon wrote:

> Scott Lurndal <scott@slp53.sl.home> wrote:
>> Jack Fearnley <jack@alcor.concordia.ca> writes:
>>> On Fri, 09 Mar 2018 18:29:25 +0000, Scott Lurndal wrote:
>>> 
>>>> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>>>>> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown
>>>>> <david.brown@hesbynett.no>
>>>>> declaimed the following:
>>>> 
>>>>> <HEH>
>>>>> 
>>>>> There is always the convention used by Xerox Sigma Fortran-IV.
>>>>> Non-recursive, non-stack...
>>>>> 
>>>>> Arguments were passed by putting them immediately after the CALL
>>>>> (branch and link opcode, and referenced by return address (saved in
>>>>> a register; I think 15 was the standard) + index.
>>>> 
>>>> This was very common in the 1970s.   The PDP-8 had similar parameter
>>>> passing as did the Burroughs B2500 and descendents until the early
>>>> 80's when a re-entrant call (Virtual Enter (VEN)) was added to the
>>>> architecture.
>>>> 
>>>> Unix system calls (UnixV6 on the PDP-11) embedded the system call
>>>> arguments in the instruction stream following the system call
>>>> instruction.
>>>> 
>>>> The B2500 system call instruction (BCT) had the following general
>>>> form:
>>>> 
>>>> BCT NNNN           # NNNN selects the system call BUN +Skip # Branch
>>>> Unconditional to after the parameters ACON label         # first
>>>> parameter (address constant)
>>>> DATA 2 UN 01       # second parameter, two digit numeric, value 01
>>>> .Skip
>>>> 
>>>> The operating system would bump the return address by the size of the
>>>> branch instruction (8 or 10 digits) to get the parameters.
>>> 
>>> Even further back. This was the standard method in the IBM1401 which I
>>> was programming in 1960.
>> 
>> The B2500 dates back to 1965, and it did have a 1401 compability mode
>> :-)
>> 
>> 
> Not a compatibility mode, but a software emulator (which was little used
> by 1967).

From what I've been told about the B2xxx and B3xxx mainframes by people 
who were developers on them they went a lot further than that - 
effectively providing a set of VMs for running applications in, e.g. 
Fortran programs ran in a stack-based environment with word addressed 
memory while COBOL programs ran in a (possibly) stack-free environment 
with byte-addressed memory. So, if they used VMs that way internally, it 
would seem natural if they had a 1401 VM (ant several others for other 
architecture

Me? I've never even set eyes on a Burroughs B-series mainframe. The 
nearest I came to that sort of experience was using a 2966 that ran two 
very different architectures simultaneously: George 3 and its applications
in a single VM [word addressed RAM using 24 bit words, 6 bit ISO 
character codes, no stack]  and VME/B and its applications in a set of VMs 
[byte addressed RAM, EBCDIC character codes and a stack-based 
architecture] and two operator's consoles - one for G3 and a second for 
VME/B
    

-- 
Martin    | martin at
Gregorie  | gregorie dot org

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

#16653

Martin Gregorie <martin@mydomain.invalid> wrote:
> On Sat, 10 Mar 2018 13:16:18 -0600, Michael J. Mahon wrote:
> 
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Jack Fearnley <jack@alcor.concordia.ca> writes:
>>>> On Fri, 09 Mar 2018 18:29:25 +0000, Scott Lurndal wrote:
>>>> 
>>>>> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>>>>>> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown
>>>>>> <david.brown@hesbynett.no>
>>>>>> declaimed the following:
>>>>> 
>>>>>> <HEH>
>>>>>> 
>>>>>> There is always the convention used by Xerox Sigma Fortran-IV.
>>>>>> Non-recursive, non-stack...
>>>>>> 
>>>>>> Arguments were passed by putting them immediately after the CALL
>>>>>> (branch and link opcode, and referenced by return address (saved in
>>>>>> a register; I think 15 was the standard) + index.
>>>>> 
>>>>> This was very common in the 1970s.   The PDP-8 had similar parameter
>>>>> passing as did the Burroughs B2500 and descendents until the early
>>>>> 80's when a re-entrant call (Virtual Enter (VEN)) was added to the
>>>>> architecture.
>>>>> 
>>>>> Unix system calls (UnixV6 on the PDP-11) embedded the system call
>>>>> arguments in the instruction stream following the system call
>>>>> instruction.
>>>>> 
>>>>> The B2500 system call instruction (BCT) had the following general
>>>>> form:
>>>>> 
>>>>> BCT NNNN           # NNNN selects the system call BUN +Skip # Branch
>>>>> Unconditional to after the parameters ACON label         # first
>>>>> parameter (address constant)
>>>>> DATA 2 UN 01       # second parameter, two digit numeric, value 01
>>>>> .Skip
>>>>> 
>>>>> The operating system would bump the return address by the size of the
>>>>> branch instruction (8 or 10 digits) to get the parameters.
>>>> 
>>>> Even further back. This was the standard method in the IBM1401 which I
>>>> was programming in 1960.
>>> 
>>> The B2500 dates back to 1965, and it did have a 1401 compability mode
>>> :-)
>>> 
>>> 
>> Not a compatibility mode, but a software emulator (which was little used
>> by 1967).
> 
> From what I've been told about the B2xxx and B3xxx mainframes by people 
> who were developers on them they went a lot further than that - 
> effectively providing a set of VMs for running applications in, e.g. 
> Fortran programs ran in a stack-based environment with word addressed 
> memory while COBOL programs ran in a (possibly) stack-free environment 
> with byte-addressed memory. So, if they used VMs that way internally, it 
> would seem natural if they had a 1401 VM (ant several others for other 
> architecture

As one of the designers of the successors to the B2500/B3500, and one of
the “variable microcode” implementors of the B1700/B1800/B1900 line of
machines, I can tell you that you are thinking of the B1700 (small systems)
line, not the B2500 (medium systems) line. 

Burroughs was a great environment for studying comparative computer
architecture, because they had so many of them! ;-)

By the time that the B1700 shipped, the IBM 1401 was no longer a
significant competitive architecture. But, you are correct that the B1700
line could have easily supported microcode (or an “S-machine”, to use
Burroughs’ parlance) to run IBM 1401 programs unchanged. 

The B1700 line was an experiment in building a machine with minimal
commitments to the higher-level architectures that it would support. For
example, the memory was bit addressable, and could fetch up to 24 bits
starting at any bit!  (This microarchitecture was inspired by Bob Barton,
who also inspired the B5000 stack architecture. Bob famously pronounced,
“In the beginning was the word, and it was the wrong size.”)

In fact, of course, maximizing effective memory bandwidth is a cardinal
responsibility of any cost-effective computer architecture, so fetching
anything less that the maximum 24 bits in a memory cycle was quite
wasteful, and most language interpreters “misused” the bit addressable
memory by making such maximal accesses and parsing bit fields in microcode.


It was a great experiment which almost immediately demonstrated that bit
addressable memory was a hardware complexity that did not result in
improved efficiency. 

> Me? I've never even set eyes on a Burroughs B-series mainframe. The 
> nearest I came to that sort of experience was using a 2966 that ran two 
> very different architectures simultaneously: George 3 and its applications
> in a single VM [word addressed RAM using 24 bit words, 6 bit ISO 
> character codes, no stack]  and VME/B and its applications in a set of VMs 
> [byte addressed RAM, EBCDIC character codes and a stack-based 
> architecture] and two operator's consoles - one for G3 and a second for 
> VME/B

There have been several “variable micrologic” computers sold. The first
that I encountered was a Raytheon machine in the early 1960s. These
machines are great vehicles for architectural experiments and perhaps have
their greatest value as platforms for emulators. But they are all less
efficient than a dedicated hardware implementation of an architecture. 

In fact, the operating system of the B1700 line, which ran on its own
interpreter, was eventually speeded up significantly by compiling important
parts of it directly to the underlying microcode. 

This is an excellent example of the fundamental RISC principle, which is
that for maximum cost-effectiveness, one should design simple hardware,
comparable to a vertically microprogrammed machine in complexity, and then
compile programs to the hardware level. 

Some characterize RISC machines as non-microprogrammed machines, but it is
equally valid to think of them as “compile to microcode” machines. In fact,
RISC machines which exploit multiple concurrent functional units are
similar to horizontally microprogrammed machines, or
VLIW machines. 

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

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

#16654

Interesting thread, but getting off-topic now for comp.sys.raspberry-pi?

-- 
Cheers,
David
Web: http://www.satsignal.eu

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

#16660

On Mon, 12 Mar 2018 01:16:16 -0500, Michael J. Mahon wrote:

> As one of the designers of the successors to the B2500/B3500, and one of
> the “variable microcode” implementors of the B1700/B1800/B1900 line of
> machines, I can tell you that you are thinking of the B1700 (small
> systems) line, not the B2500 (medium systems) line.
>
Fair enough, and thanks for providing such a good summary of the 
Burroughs range.

The ICL 1900 range were all fairly simple beasts that used 24 bit words, 
split into 4 6-bit ISO-code characters and did not implement a stack.
There were only two hardware registers, which held datum and limit for 
the executing program. Since all program addressing was relative to 
datum, and the first few words of a program contained the 8 program-
accessible registers PC and instruction result bit flags, programs could 
be easily swapped in and out of RAM without regard for where they were 
reloaded. They also used 'extracodes' - each of these was an opcode that 
was implemented by an OS module. Some instructions, e.g. for i/o were 
implemented as extracode on all 190 models, while others, e.g. floating 
point operations were hardware operations on the bigger machines and 
extracodes on lesser systems. The effect was that any 1900 program would 
run on any system with enough memory and the appropriate peripherals.

> Burroughs was a great environment for studying comparative computer
> architecture, because they had so many of them! ;-)
>
:-)
 

-- 
Martin    | martin at
Gregorie  | gregorie dot org

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

#16656

Martin Gregorie <martin@mydomain.invalid> writes:
>On Sat, 10 Mar 2018 13:16:18 -0600, Michael J. Mahon wrote:
>
>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>> Jack Fearnley <jack@alcor.concordia.ca> writes:
>>>> On Fri, 09 Mar 2018 18:29:25 +0000, Scott Lurndal wrote:
>>>> 
>>>>> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>>>>>> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown
>>>>>> <david.brown@hesbynett.no>
>>>>>> declaimed the following:
>>>>> 
>>>>>> <HEH>
>>>>>> 
>>>>>> There is always the convention used by Xerox Sigma Fortran-IV.
>>>>>> Non-recursive, non-stack...
>>>>>> 
>>>>>> Arguments were passed by putting them immediately after the CALL
>>>>>> (branch and link opcode, and referenced by return address (saved in
>>>>>> a register; I think 15 was the standard) + index.
>>>>> 
>>>>> This was very common in the 1970s.   The PDP-8 had similar parameter
>>>>> passing as did the Burroughs B2500 and descendents until the early
>>>>> 80's when a re-entrant call (Virtual Enter (VEN)) was added to the
>>>>> architecture.
>>>>> 
>>>>> Unix system calls (UnixV6 on the PDP-11) embedded the system call
>>>>> arguments in the instruction stream following the system call
>>>>> instruction.
>>>>> 
>>>>> The B2500 system call instruction (BCT) had the following general
>>>>> form:
>>>>> 
>>>>> BCT NNNN           # NNNN selects the system call BUN +Skip # Branch
>>>>> Unconditional to after the parameters ACON label         # first
>>>>> parameter (address constant)
>>>>> DATA 2 UN 01       # second parameter, two digit numeric, value 01
>>>>> .Skip
>>>>> 
>>>>> The operating system would bump the return address by the size of the
>>>>> branch instruction (8 or 10 digits) to get the parameters.
>>>> 
>>>> Even further back. This was the standard method in the IBM1401 which I
>>>> was programming in 1960.
>>> 
>>> The B2500 dates back to 1965, and it did have a 1401 compability mode
>>> :-)
>>> 
>>> 
>> Not a compatibility mode, but a software emulator (which was little used
>> by 1967).
>
>From what I've been told about the B2xxx and B3xxx mainframes by people 

Burroughs had three lines of mainframes:

  Small Systems (B1700/B1800/B1900)
  Medium Systems (B2x00/B3x00/B4x00)
  Large Systems (B5x00/B6x00/B7x00)

>who were developers on them they went a lot further than that - 
>effectively providing a set of VMs for running applications in, e.g. 
>Fortran programs ran in a stack-based environment with word addressed 
>memory while COBOL programs ran in a (possibly) stack-free environment 
>with byte-addressed memory. So, if they used VMs that way internally, it 
>would seem natural if they had a 1401 VM (ant several others for other 
>architecture

You're describing the small systems architecture which came along
in the 70's.

The B3500 (derived in part from the B300, which history includes the
electrodata 220) was the first system in the Medium Systems line
(a BCD machine addressed to the digit, designed to run COBOL).

The B5500 (follow on to the famous B5000) was the first system in
the large systems line (36-bit word, stack-based capability architecture;
buffer overflows are impossible!).

The Large systems lives on today in the Unisys Clearpath machines
(emulated on x86).

>
>Me? I've never even set eyes on a Burroughs B-series mainframe. 

I worked on the medium systems MCP for 7 years, wrote the software
stack from power-on to system idle, and the data communications stack.

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

#16657

Scott Lurndal <scott@slp53.sl.home> wrote:
> Martin Gregorie <martin@mydomain.invalid> writes:
>> On Sat, 10 Mar 2018 13:16:18 -0600, Michael J. Mahon wrote:
>> 
>>> Scott Lurndal <scott@slp53.sl.home> wrote:
>>>> Jack Fearnley <jack@alcor.concordia.ca> writes:
>>>>> On Fri, 09 Mar 2018 18:29:25 +0000, Scott Lurndal wrote:
>>>>> 
>>>>>> Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>>>>>>> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown
>>>>>>> <david.brown@hesbynett.no>
>>>>>>> declaimed the following:
>>>>>> 
>>>>>>> <HEH>
>>>>>>> 
>>>>>>> There is always the convention used by Xerox Sigma Fortran-IV.
>>>>>>> Non-recursive, non-stack...
>>>>>>> 
>>>>>>> Arguments were passed by putting them immediately after the CALL
>>>>>>> (branch and link opcode, and referenced by return address (saved in
>>>>>>> a register; I think 15 was the standard) + index.
>>>>>> 
>>>>>> This was very common in the 1970s.   The PDP-8 had similar parameter
>>>>>> passing as did the Burroughs B2500 and descendents until the early
>>>>>> 80's when a re-entrant call (Virtual Enter (VEN)) was added to the
>>>>>> architecture.
>>>>>> 
>>>>>> Unix system calls (UnixV6 on the PDP-11) embedded the system call
>>>>>> arguments in the instruction stream following the system call
>>>>>> instruction.
>>>>>> 
>>>>>> The B2500 system call instruction (BCT) had the following general
>>>>>> form:
>>>>>> 
>>>>>> BCT NNNN           # NNNN selects the system call BUN +Skip # Branch
>>>>>> Unconditional to after the parameters ACON label         # first
>>>>>> parameter (address constant)
>>>>>> DATA 2 UN 01       # second parameter, two digit numeric, value 01
>>>>>> .Skip
>>>>>> 
>>>>>> The operating system would bump the return address by the size of the
>>>>>> branch instruction (8 or 10 digits) to get the parameters.
>>>>> 
>>>>> Even further back. This was the standard method in the IBM1401 which I
>>>>> was programming in 1960.
>>>> 
>>>> The B2500 dates back to 1965, and it did have a 1401 compability mode
>>>> :-)
>>>> 
>>>> 
>>> Not a compatibility mode, but a software emulator (which was little used
>>> by 1967).
>> 
>> From what I've been told about the B2xxx and B3xxx mainframes by people 
> 
> Burroughs had three lines of mainframes:
> 
>   Small Systems (B1700/B1800/B1900)
>   Medium Systems (B2x00/B3x00/B4x00)
>   Large Systems (B5x00/B6x00/B7x00)
> 
>> who were developers on them they went a lot further than that - 
>> effectively providing a set of VMs for running applications in, e.g. 
>> Fortran programs ran in a stack-based environment with word addressed 
>> memory while COBOL programs ran in a (possibly) stack-free environment 
>> with byte-addressed memory. So, if they used VMs that way internally, it 
>> would seem natural if they had a 1401 VM (ant several others for other 
>> architecture
> 
> You're describing the small systems architecture which came along
> in the 70's.
> 
> The B3500 (derived in part from the B300, which history includes the
> electrodata 220) was the first system in the Medium Systems line
> (a BCD machine addressed to the digit, designed to run COBOL).
> 
> The B5500 (follow on to the famous B5000) was the first system in
> the large systems line (36-bit word, stack-based capability architecture;
> buffer overflows are impossible!).
> 
> The Large systems lives on today in the Unisys Clearpath machines
> (emulated on x86).
> 
>> 
>> Me? I've never even set eyes on a Burroughs B-series mainframe. 
> 
> I worked on the medium systems MCP for 7 years, wrote the software
> stack from power-on to system idle, and the data communications stack.
> 

Hi, Scott!  I was in the Medium Systems MCP group from 1968 to 1978—almost
went to Goleta with the B1700 (née B1500) folks!

AOK except that the B5000 line had 48-bit words. ;-)

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

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

#16659

Michael J. Mahon <mjmahon@aol.com> writes:
>Scott Lurndal <scott@slp53.sl.home> wrote:

>> I worked on the medium systems MCP for 7 years, wrote the software
>> stack from power-on to system idle, and the data communications stack.
>> 
>
>Hi, Scott!  I was in the Medium Systems MCP group from 1968 to 1978—almost
>went to Goleta with the B1700 (née B1500) folks!

Hi Michael,

 Just missed you then, I started in '83 on the Omega
project (they must have just been starting the B4900
design about when you left).

Check out <http://vseries.lurndal.org/>.

Now Goleta, that would have been nicer than Pasadena.   Bud Keeley
always said the Santa Barbara area was nice...

>
>AOK except that the B5000 line had 48-bit words. ;-)

Shoot, and I knew that (although I only used the B7900 a
couple of times).  Been looking at the CHERI project
(capabilities are coming back!), and have spent too much
time on afc talking about the PDP-10 (36-bit).

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.sys.raspberry-pi

csiph-web