Hi,

Could anyone suggest a program with a decent amount of C and MACRO code?
 I'm also after suggestions as to what library I should use to write a
character-terminal screen based application in C/MACRO.

Thanks for the help,

Mark.

On Nov 26, 4:39=A0pm, Mark Wickens <m...@wickensonline.co.uk> wrote:
> Hi,
>
> Could anyone suggest a program with a decent amount of C and MACRO code?
> =A0I'm also after suggestions as to what library I should use to write a
> character-terminal screen based application in C/MACRO.
>
> Thanks for the help,
>
> Mark.


Have a wander though the vms freeware collections. http://mvb.saic.com/
Most are not large programs including mine

Many years ago I wrote a piece of Macro32 to implement a dumb terminal field 
editor

Lots of handling QIO calls, idea was to be able to specify a field in the 
24*80 screen co ordinates, a pre filled string for the field if appropriate, 
string length. numeric only, alpha numeric, auto upper/lower case, 
insert/overwrite  etc. As well as returning the field content to the calling 
program, I also returned the method by which the field completed, as in 
left/right arrow field overrun, or up/down. the calling program then jumped 
to the appropriate next/previous field etc.

It was probably not the most elegant piece of code, but predated DEC 
implimenting in-field editing. It quickly became my companies standard for 
handling screen I/O, and led to lots of complaints from later developers who 
tried to port the code to PCs and found they did not understand a strange 
call to "fedit" or field edit. This then became the underlying tool for a 
form definition tool we developed.

Pity when they knocked our office block down, the vax systems were still in 
the computer room and I never got the chance to offload my code 

  On Nov 26, 4:39 pm, Mark Wickens <m...@wickensonline.co.uk> wrote:
> Hi,
>
> Could anyone suggest a program with a decent amount of C and MACRO code?
>  I'm also after suggestions as to what library I should use to write a
> character-terminal screen based application in C/MACRO.
>
> Thanks for the help,
>
> Mark.

I can't help to ask, why ?
Why write an "application" (whatever that is) in MACRO ?

And, as have said, a lot of the VMS freeware tools are
probably written in MACRO and/or C.

On Nov 26, 4:39=A0pm, Mark Wickens <m...@wickensonline.co.uk> wrote:

> Could anyone suggest a program with a decent amount of C and MACRO code?
> I'm also after suggestions as to what library I should use to write a
> character-terminal screen based application in C/MACRO.

It's normally best to avoid Macro unless you're writing something where
you need absolute control of what is going on, or in an abnormal/unusual
environment.  This is normally things like system or boot code, drivers 
etc. and nowadays many of these can be written in languages like C.

Mark Wickens wrote:

> Could anyone suggest a program with a decent amount of C and MACRO code?
>  I'm also after suggestions as to what library I should use to write a
> character-terminal screen based application in C/MACRO.

My first thought was Kermit, but I believe that is mostly Bliss-32.

The beginning of VMS was before C, or at least before C was
well known.

Kermit is a character/terminal screen based application, though.

-- glen

Jan-Erik S�derholm wrote:
>  On Nov 26, 4:39 pm, Mark Wickens <m...@wickensonline.co.uk> wrote:
>> Hi,
>>
>> Could anyone suggest a program with a decent amount of C and MACRO code?
>>  I'm also after suggestions as to what library I should use to write a
>> character-terminal screen based application in C/MACRO.
>>
>> Thanks for the help,
>>
>> Mark.
> 
> I can't help to ask, why ?
> Why write an "application" (whatever that is) in MACRO ?
> 
> And, as have said, a lot of the VMS freeware tools are
> probably written in MACRO and/or C.

Thanks for the replies - yes asking 'why' is a good question.

This is purely an academic exercise - I am doing my 'learn one language
a year' and this year it is MACRO-32. I have done more than my fair
share of C programming, but I'm now entrenched in the Java/Web
programming arena. As programming for the internet is my day job I
wanted a suitably different scenario to 'play' with.

To be honest I'm pretty sick of web programming. It would be hard to
think of a more clunky way of providing a minimal level of user
interaction. I've investigated a number of options, the most pure of
which appears to be google web toolkit (pure-java based solution that
autogenerates the required client side javascript) but they're all
horrible - either everything happens in one window (so page
navigation/bookmarking doesn't work) or every interaction must fit into
the web 'page-at-a-time' cycle. Bolt on functionality that would be
integral to any decent application development environment has to be
performed using highly browser-dependent javascript (don't even get me
started with that!)

I've done Java Swing programming before which is where the 'application'
part of the requirement comes into it. More flexible interaction is
great and entirely possible, but at the cost of increased complexity.

I'd welcome anyones experience of application development using other
tools and languages. I find that most of the people I work with now have
a very narrowly-focused mindset based exclusively around web development.

I looked at character-based application toolkits, and just decided that
as I have no 'run-everywhere' requirement I would concentrate on
developing for a platform and toolset which is stable and reliable -
OpenVMS. In that sense I would like to broker people's opinions on the
'nicest' screen-oriented library available for the platform. I've come
across ncurses before and wondered if any of the VMS-specific libraries
offer a more pleasant development experience.

Kind regards,

Mark.

In article <ggk6g2$34q$1@pcls6.std.com>, moroney@world.std.spaamtrap.com (Michael Moroney) writes:
>On Nov 26, 4:39=A0pm, Mark Wickens <m...@wickensonline.co.uk> wrote:
>
>> Could anyone suggest a program with a decent amount of C and MACRO code?
>> I'm also after suggestions as to what library I should use to write a
>> character-terminal screen based application in C/MACRO.
>
>It's normally best to avoid Macro unless you're writing something where
>you need absolute control of what is going on, or in an abnormal/unusual
>environment.  This is normally things like system or boot code, drivers 
>etc. and nowadays many of these can be written in languages like C.

....and, in many cases, with great difficulty.  I prefer Macro because it
has a macro capability.  This is, IMHO, one of the biggest drawbacks to
C.  Oh, did I mention fighting anal retentive typing rules?

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.

On Wed, 26 Nov 2008 19:46:29 UTC,   VAXman-  @SendSpamHere.ORG wrote:

> In article <ggk6g2$34q$1@pcls6.std.com>, moroney@world.std.spaamtrap.com (Michael Moroney) writes:
> >On Nov 26, 4:39=A0pm, Mark Wickens <m...@wickensonline.co.uk> wrote:
> >
> >> Could anyone suggest a program with a decent amount of C and MACRO code?
> >> I'm also after suggestions as to what library I should use to write a
> >> character-terminal screen based application in C/MACRO.
> >
> >It's normally best to avoid Macro unless you're writing something where
> >you need absolute control of what is going on, or in an abnormal/unusual
> >environment.  This is normally things like system or boot code, drivers 
> >etc. and nowadays many of these can be written in languages like C.
> 
> ...and, in many cases, with great difficulty.  I prefer Macro because it
> has a macro capability.  This is, IMHO, one of the biggest drawbacks to
> C.  Oh, did I mention fighting anal retentive typing rules?

C does of course have a macro capability, even if it is rather limited. 
Personally, in that situation I use a dedicated macro processor for a 
prepass. And I don't mean the abortion known as m4. See:   
http://www.ml1.org.uk

I have one or two large-ish Macro-32 programs if the OP wants to peruse 
them. They are pretty heavily commented and use various library 
facilities (but not screen operations).

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

On Nov 26, 2:38=A0pm, Mark Wickens <m...@wickensonline.co.uk> wrote:
> I'd welcome anyones experience of application development using other
> tools and languages.

For browser-based applications?

My preference is Java applets.  Complex perhaps, but no less than all
these other competing technologies that are trying to get real
applications into a browser.

"Mark Wickens" <mark@wickensonline.co.uk> wrote in message 
news:ggk8j0$gpo$1@news.motzarella.org...
> This is purely an academic exercise - I am doing my 'learn one language
> a year' and this year it is MACRO-32.

Not to discourage you, but honestly why learn the instruction set of a 
computer from the 1970's which isn't even made anymore?

At least do X86 or Itanium assembly if you must satisify some urge to 
twiddle bits.

Personally, as a language person, I'd go learn Ruby or perhaps go volunteer 
to help out with MMIX (Knuth's replacement for MIX)

John Reagan
Macro-32 Project Leader 

Mark Wickens wrote:
> Could anyone suggest a program with a decent amount of C and MACRO code?

C is easy. 3/4 of the freeware for VMS are written in C.

Macro-32 is more difficult. The freeware stuff I am aware of typical
have no Macro-32 or only a single file like HPWD.MAR.

If you want I can email you some thousands of lines of assorted
utilities I have written in Macro-32.

>  I'm also after suggestions as to what library I should use to write a
> character-terminal screen based application in C/MACRO.

VMS only: SMG$

Portable: curses

And in my opinion SMG$ are really nice !

Arne

Michael Moroney wrote:
> On Nov 26, 4:39=A0pm, Mark Wickens <m...@wickensonline.co.uk> wrote:
>> Could anyone suggest a program with a decent amount of C and MACRO code?
>> I'm also after suggestions as to what library I should use to write a
>> character-terminal screen based application in C/MACRO.
> 
> It's normally best to avoid Macro unless you're writing something where
> you need absolute control of what is going on, or in an abnormal/unusual
> environment.  This is normally things like system or boot code, drivers 
> etc. and nowadays many of these can be written in languages like C.

It is also worth noting that Macro-32 has been compiled not native
assembler the last 15 years, so it really does not give absolute
control any more.

Arne

VAXman- @SendSpamHere.ORG wrote:
> ...and, in many cases, with great difficulty.  I prefer Macro because it
> has a macro capability.  This is, IMHO, one of the biggest drawbacks to
> C.  Oh, did I mention fighting anal retentive typing rules?

C has macros.

Arne

FrankS wrote:
> On Nov 26, 2:38 pm, Mark Wickens <m...@wickensonline.co.uk> wrote:
>> I'd welcome anyones experience of application development using other
>> tools and languages.
> 
> For browser-based applications?
> 
> My preference is Java applets.  Complex perhaps, but no less than all
> these other competing technologies that are trying to get real
> applications into a browser.

Java applets are not in fashion today.

But if one happen to program in Java, then it is an
obvious choice.

Arne

Mark Wickens wrote:
> I looked at character-based application toolkits, and just decided that
> as I have no 'run-everywhere' requirement I would concentrate on
> developing for a platform and toolset which is stable and reliable -
> OpenVMS. In that sense I would like to broker people's opinions on the
> 'nicest' screen-oriented library available for the platform. I've come
> across ncurses before and wondered if any of the VMS-specific libraries
> offer a more pleasant development experience.

Go for SMG$.

Arne

VAXman- @SendSpamHere.ORG wrote:
> In article <ggk6g2$34q$1@pcls6.std.com>, moroney@world.std.spaamtrap.com (Michael Moroney) writes:
>> On Nov 26, 4:39=A0pm, Mark Wickens <m...@wickensonline.co.uk> wrote:
>>
>>> Could anyone suggest a program with a decent amount of C and MACRO code?
>>> I'm also after suggestions as to what library I should use to write a
>>> character-terminal screen based application in C/MACRO.
>> It's normally best to avoid Macro unless you're writing something where
>> you need absolute control of what is going on, or in an abnormal/unusual
>> environment.  This is normally things like system or boot code, drivers 
>> etc. and nowadays many of these can be written in languages like C.
> 
> ...and, in many cases, with great difficulty.  I prefer Macro because it
> has a macro capability.  This is, IMHO, one of the biggest drawbacks to
> C.  Oh, did I mention fighting anal retentive typing rules?
> 

And just what is wrong with anal retentive typing rules?  I'd say that a 
substantial number of bugs are due to incorrect typing.  Store a long 
where a short should be and watch the screwups happen.  Store a float 
where an int should be. . . .

There are a few situations where a programmer must work around the 
typing rules.  They are rare and generally occur when somebody has to 
convert binary data from platform "A" for use on platform "B".

Mark Wickens wrote:
> Jan-Erik S�derholm wrote:
>> I can't help to ask, why ?
>> Why write an "application" (whatever that is) in MACRO ?

> Thanks for the replies - yes asking 'why' is a good question.
> 
> This is purely an academic exercise - I am doing my 'learn one language
> a year' and this year it is MACRO-32.

If you want to code in assembler, then Macro-32 is probably one
of the easiest instruction sets to code in - its CISC'ness
makes it much easier that anything else I have tried.

But note that VAX'es stopped being produced in the mid 90's.

Arne

Glen Herrmannsfeldt wrote:
> Mark Wickens wrote:
> 
>> Could anyone suggest a program with a decent amount of C and MACRO code?
>>  I'm also after suggestions as to what library I should use to write a
>> character-terminal screen based application in C/MACRO.
> 
> My first thought was Kermit, but I believe that is mostly Bliss-32.
> 

I was about to say that Kermit is written in C. However, just
for my own curiosity I decided to check this out. You are correct.
There was a version called KERMIT-32 for VMS that was written in
BLISS! From what I can see of the source it was common between
the VAX, PDP-10 and PDP-11 architectures.

These days C-Kermit has been ported to VMS.

Tim.

Tim E. Sneddon wrote:
> Glen Herrmannsfeldt wrote:
>> Mark Wickens wrote:
>>
>>> Could anyone suggest a program with a decent amount of C and MACRO code?
>>>  I'm also after suggestions as to what library I should use to write a
>>> character-terminal screen based application in C/MACRO.
>>
>> My first thought was Kermit, but I believe that is mostly Bliss-32.
> 
> I was about to say that Kermit is written in C. However, just
> for my own curiosity I decided to check this out. You are correct.
> There was a version called KERMIT-32 for VMS that was written in
> BLISS! From what I can see of the source it was common between
> the VAX, PDP-10 and PDP-11 architectures.
> 
> These days C-Kermit has been ported to VMS.

These days is since 1990 or something like that.

Arne

John Reagan wrote:
> "Mark Wickens" <mark@wickensonline.co.uk> wrote in message 
> news:ggk8j0$gpo$1@news.motzarella.org...
>> This is purely an academic exercise - I am doing my 'learn one language
>> a year' and this year it is MACRO-32.
> 
> Not to discourage you, but honestly why learn the instruction set of a 
> computer from the 1970's which isn't even made anymore?
> 
> At least do X86 or Itanium assembly if you must satisify some urge to 
> twiddle bits.
> 

Anyone who *willingly* chooses Itanium assembly to write anything
should immediately get themselves to a doctor!

Tim.

Arne Vajh�j wrote:
> Mark Wickens wrote:
>> Jan-Erik S�derholm wrote:
>>> I can't help to ask, why ?
>>> Why write an "application" (whatever that is) in MACRO ?
> 
>> Thanks for the replies - yes asking 'why' is a good question.
>>
>> This is purely an academic exercise - I am doing my 'learn one language
>> a year' and this year it is MACRO-32.
> 
> If you want to code in assembler, then Macro-32 is probably one
> of the easiest instruction sets to code in - its CISC'ness
> makes it much easier that anything else I have tried.
> 
> But note that VAX'es stopped being produced in the mid 90's.
> 

But note that, given the proper software, you can compile VAX Macro to 
produce Alpha object code.  I wouldn't be surprised if this could also 
be done on Itanic.

ISTR doing this once nine or ten years ago.  I had some useful snippet 
written in macro and wanted to use it on Alpha. . . .

There is little reason to write anything in Macro today; device drivers 
can be written in C.  What else was Macro good for?

The days when the ability to hand optimize code was useful are long gone 
along with the machines on which hand optimization could make a 
significant difference!

Richard B. Gilbert wrote:
> Arne Vajh�j wrote:
>> But note that VAX'es stopped being produced in the mid 90's.
> 
> But note that, given the proper software, you can compile VAX Macro to 
> produce Alpha object code.  I wouldn't be surprised if this could also 
> be done on Itanic.

I do have a VMS I64 box, but I assume it can.

I don't think HP wanted to port the Macro-32 parts
of VMS to another language.

Arne

Arne Vajh�j wrote:
> Richard B. Gilbert wrote:
>> Arne Vajh�j wrote:
>>> But note that VAX'es stopped being produced in the mid 90's.
>>
>> But note that, given the proper software, you can compile VAX Macro to 
>> produce Alpha object code.  I wouldn't be surprised if this could also 
>> be done on Itanic.
> 
> I do have a VMS I64 box, but I assume it can.
> 
> I don't think HP wanted to port the Macro-32 parts
> of VMS to another language.

wanted = wanted to pay what it cost

Arne

In article <176uZD2KcidF-pn2-XkFoOd5qXG45@rikki.tavi.co.uk>, "Bob Eager" <rde42@spamcop.net> writes:
>On Wed, 26 Nov 2008 19:46:29 UTC,   VAXman-  @SendSpamHere.ORG wrote:
>
>> In article <ggk6g2$34q$1@pcls6.std.com>, moroney@world.std.spaamtrap.com (Michael Moroney) writes:
>> >On Nov 26, 4:39=A0pm, Mark Wickens <m...@wickensonline.co.uk> wrote:
>> >
>> >> Could anyone suggest a program with a decent amount of C and MACRO code?
>> >> I'm also after suggestions as to what library I should use to write a
>> >> character-terminal screen based application in C/MACRO.
>> >
>> >It's normally best to avoid Macro unless you're writing something where
>> >you need absolute control of what is going on, or in an abnormal/unusual
>> >environment.  This is normally things like system or boot code, drivers 
>> >etc. and nowadays many of these can be written in languages like C.
>> 
>> ...and, in many cases, with great difficulty.  I prefer Macro because it
>> has a macro capability.  This is, IMHO, one of the biggest drawbacks to
>> C.  Oh, did I mention fighting anal retentive typing rules?
>
>C does of course have a macro capability, even if it is rather limited. 
>Personally, in that situation I use a dedicated macro processor for a 
>prepass. And I don't mean the abortion known as m4. See:   
>http://www.ml1.org.uk

One man's "macro" capability is another man's brain-damaged lame 
string substitution.


>I have one or two large-ish Macro-32 programs if the OP wants to peruse 
>them. They are pretty heavily commented and use various library 
>facilities (but not screen operations).

I have one largish macro (700 lines) that implements system service
interception on VAX, Alpha and Itanium.  Try doing that with C's so-
called macro capability!

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.

In article <26lXk.1240$Et1.966@news-server.bigpond.net.au>, "Tim E. Sneddon" <tesneddon@bigpond.com> writes:
>John Reagan wrote:
>> "Mark Wickens" <mark@wickensonline.co.uk> wrote in message 
>> news:ggk8j0$gpo$1@news.motzarella.org...
>>> This is purely an academic exercise - I am doing my 'learn one language
>>> a year' and this year it is MACRO-32.
>> 
>> Not to discourage you, but honestly why learn the instruction set of a 
>> computer from the 1970's which isn't even made anymore?
>> 
>> At least do X86 or Itanium assembly if you must satisify some urge to 
>> twiddle bits.
>> 
>
>Anyone who *willingly* chooses Itanium assembly to write anything
>should immediately get themselves to a doctor!

Do I really need to run out RIGHT THIS INSTANT?

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.

On Thu, 27 Nov 2008 00:33:04 UTC,   VAXman-  @SendSpamHere.ORG wrote:

> In article <176uZD2KcidF-pn2-XkFoOd5qXG45@rikki.tavi.co.uk>, "Bob Eager" <rde42@spamcop.net> writes:
> >On Wed, 26 Nov 2008 19:46:29 UTC,   VAXman-  @SendSpamHere.ORG wrote:
> >
> >> In article <ggk6g2$34q$1@pcls6.std.com>, moroney@world.std.spaamtrap.com (Michael Moroney) writes:
> >> >On Nov 26, 4:39=A0pm, Mark Wickens <m...@wickensonline.co.uk> wrote:
> >> >
> >> >> Could anyone suggest a program with a decent amount of C and MACRO code?
> >> >> I'm also after suggestions as to what library I should use to write a
> >> >> character-terminal screen based application in C/MACRO.
> >> >
> >> >It's normally best to avoid Macro unless you're writing something where
> >> >you need absolute control of what is going on, or in an abnormal/unusual
> >> >environment.  This is normally things like system or boot code, drivers 
> >> >etc. and nowadays many of these can be written in languages like C.
> >> 
> >> ...and, in many cases, with great difficulty.  I prefer Macro because it
> >> has a macro capability.  This is, IMHO, one of the biggest drawbacks to
> >> C.  Oh, did I mention fighting anal retentive typing rules?
> >
> >C does of course have a macro capability, even if it is rather limited. 
> >Personally, in that situation I use a dedicated macro processor for a 
> >prepass. And I don't mean the abortion known as m4. See:   
> >http://www.ml1.org.uk
> 
> One man's "macro" capability is another man's brain-damaged lame 
> string substitution.

For C, I'd agree.

> >I have one or two large-ish Macro-32 programs if the OP wants to peruse 
> >them. They are pretty heavily commented and use various library 
> >facilities (but not screen operations).
> 
> I have one largish macro (700 lines) that implements system service
> interception on VAX, Alpha and Itanium.  Try doing that with C's so-
> called macro capability!

But Macro-32 is still weak compared to a dedicated macro processor.

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

In article <492dcf0f$0$90264$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>VAXman- @SendSpamHere.ORG wrote:
>> ...and, in many cases, with great difficulty.  I prefer Macro because it
>> has a macro capability.  This is, IMHO, one of the biggest drawbacks to
>> C.  Oh, did I mention fighting anal retentive typing rules?
>
>C has macros.

Having coded in both Bliss and Macro, to call C's string substitution
'macros' is uproarious.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.

VAXman- @SendSpamHere.ORG wrote:
> In article <26lXk.1240$Et1.966@news-server.bigpond.net.au>, "Tim E. Sneddon" <tesneddon@bigpond.com> writes:
>> John Reagan wrote:
>>> "Mark Wickens" <mark@wickensonline.co.uk> wrote in message 
>>> news:ggk8j0$gpo$1@news.motzarella.org...
>>>> This is purely an academic exercise - I am doing my 'learn one language
>>>> a year' and this year it is MACRO-32.
>>> Not to discourage you, but honestly why learn the instruction set of a 
>>> computer from the 1970's which isn't even made anymore?
>>>
>>> At least do X86 or Itanium assembly if you must satisify some urge to 
>>> twiddle bits.
>>>
>> Anyone who *willingly* chooses Itanium assembly to write anything
>> should immediately get themselves to a doctor!
> 
> Do I really need to run out RIGHT THIS INSTANT?
> 

It can probably wait till tomorrow :-) There wasn't much the
doctor could do for me. I just have to live with the ticks
and twitches :-)

Tim.

VAXman- @SendSpamHere.ORG wrote:
> In article <492dcf0f$0$90264$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>> VAXman- @SendSpamHere.ORG wrote:
>>> ...and, in many cases, with great difficulty.  I prefer Macro because it
>>> has a macro capability.  This is, IMHO, one of the biggest drawbacks to
>>> C.  Oh, did I mention fighting anal retentive typing rules?
>> C has macros.
> 
> Having coded in both Bliss and Macro, to call C's string substitution
> 'macros' is uproarious.
> 

I couldn't agree more. BLISS has a fantastic and *very*
extensive macro language. The only time I have wished
for *at least* C's 'macros' is when I was trying to use
the pre-processor on the BASIC compiler.

Tim.

On Wed, 26 Nov 2008 08:39:03 -0800, Mark Wickens  
<mark@wickensonline.co.uk> wrote:

> Hi,
>
> Could anyone suggest a program with a decent amount of C and MACRO code?
>  I'm also after suggestions as to what library I should use to write a
> character-terminal screen based application in C/MACRO.
>
> Thanks for the help,
>
> Mark.

"Good example in C" I would suggest is an oxymoron.


http://www.kednos.com/pli_examples/00914629-969CB160-1C01E7.HTML
How To Use SMG To Format A Screen Display</title>

http://www.kednos.com/pli_examples/00921D47-285505E0-1C01E7.HTML
Example PL1 Using SMG$SNAPSHOT to Write an SMG Pasteboard to a File

http://www.kednos.com/pli_examples/00921D6D-F27A5520-1C01E7.HTML
Run-Time Error Using SMG$CREATE_MENU From A PL1 Program

http://www.kednos.com/pli_examples/0095BCBA-773E5380-1C0097.HTML
SMG$READ_STRING Using Arrows as Terminators

-- 
PL/I for OpenVMS
www.kednos.com

Bob Eager wrote:

> I have one or two large-ish Macro-32 programs if the OP wants to peruse 
> them. They are pretty heavily commented and use various library 
> facilities (but not screen operations).

And I have 100,000 lines of Macro-32 as an example of how NOT to write 
Macro-32!



Arne Vajhoej wrote:

> It is also worth noting that Macro-32 has been compiled not native
> assembler the last 15 years, so it really does not give absolute
> control any more.

Oh, don't I know it, trying to get the 100K mess running on an Itanic.



Richard Gilbert wrote:

> But note that, given the proper software, you can compile VAX Macro to 
> produce Alpha object code.  I wouldn't be surprised if this could also 
> be done on Itanic.

Yes, the Macro-32 compiler comes with VMS on Alpha as well as VMS on 
Itanic.  I believe they're both the same code except for the part that
actually generates the resulting object code.  (I've found bugs that exist
on both the Alpha and Itanic Macro-32 compilers)

On Wed, 26 Nov 2008 19:08:53 -0800, Michael Moroney  
<moroney@world.std.spaamtrap.com> wrote:

> Bob Eager wrote:
>
>> I have one or two large-ish Macro-32 programs if the OP wants to peruse
>> them. They are pretty heavily commented and use various library
>> facilities (but not screen operations).
>
> And I have 100,000 lines of Macro-32 as an example of how NOT to write
> Macro-32!
>
>
>
> Arne Vajhoej wrote:
>
>> It is also worth noting that Macro-32 has been compiled not native
>> assembler the last 15 years, so it really does not give absolute
>> control any more.
>
> Oh, don't I know it, trying to get the 100K mess running on an Itanic.
>
>
>
> Richard Gilbert wrote:
>
>> But note that, given the proper software, you can compile VAX Macro to
>> produce Alpha object code.  I wouldn't be surprised if this could also
>> be done on Itanic.
>
> Yes, the Macro-32 compiler comes with VMS on Alpha as well as VMS on
> Itanic.  I believe they're both the same code except for the part that
> actually generates the resulting object code.  (I've found bugs that  
> exist
> on both the Alpha and Itanic Macro-32 compilers)

Using Macro 32 on anything but a VAX is ill-advised, in fact it probably
should have been avoided on the VAX as well.

-- 
PL/I for OpenVMS
www.kednos.com

"Michael Moroney" <moroney@world.std.spaamtrap.com> wrote in message 
news:ggl305$c38$1@pcls6.std.com...
> Yes, the Macro-32 compiler comes with VMS on Alpha as well as VMS on
> Itanic.  I believe they're both the same code except for the part that
> actually generates the resulting object code.  (I've found bugs that exist
> on both the Alpha and Itanic Macro-32 compilers)

Ayup.  You are correct.  They have the same parser, same flow analyzer (with 
a few conditionalizations to deal with calling standard differences), but 
different code generators.  The I64 code generator for Macro-32 was created 
by starting with the Alpha version and recoding just about every routine.

Unlike the other compilers, Macro-32's use of GEM is different.  It does not 
generate the high-level CIL, but rather bypasses most of GEM and generates 
code-cells directly that are feed back into GEM at a low level.  It only 
uses GEM for peephole optimization, instruction scheduling/bundling, and 
things like object/listing file generation.

John 

Michael Moroney wrote:
> Arne Vajhoej wrote:
>> It is also worth noting that Macro-32 has been compiled not native
>> assembler the last 15 years, so it really does not give absolute
>> control any more.
> 
> Oh, don't I know it, trying to get the 100K mess running on an Itanic.

There are still a difference.

On VAX it was all you and the HW engineer.

On Alpha and I64 it is you, the compiler writer
and the HW engineer.

Macro-32 does not give you full control over
the code.

Arne

Richard B. Gilbert wrote:

> There is little reason to write anything in Macro today; device drivers 
> can be written in C.  What else was Macro good for?


Making transfer vectors for sharable images ? Are there now tools to
make those without Macro ?

Tim E. Sneddon wrote:
(snip)

> Anyone who *willingly* chooses Itanium assembly to write anything
> should immediately get themselves to a doctor!

VAX is probably one of the easier assembly languages to learn.

PDP-11 and S/360 also aren't so bad.

I haven't tried Itanium yet, and I don't know that I want to,
but I will soon have one to try it on.

-- glen

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:

>Michael Moroney wrote:
>> Arne Vajhoej wrote:
>>> It is also worth noting that Macro-32 has been compiled not native
>>> assembler the last 15 years, so it really does not give absolute
>>> control any more.
>> 
>> Oh, don't I know it, trying to get the 100K mess running on an Itanic.

>There are still a difference.

>On VAX it was all you and the HW engineer.

>On Alpha and I64 it is you, the compiler writer
>and the HW engineer.

>Macro-32 does not give you full control over
>the code.

I was agreeing with you.  Those people were doing things on the VAX that
while crazy, did work (such as referencing variables in the calling
routine on the stack, "above" the called routine's portion).  The
Alpha/Itanic compilers flag that as an error. Only reasonably sane
Macro-32 code will compile, while the VAX will accept almost anything with
correct syntax.

JF Mezei wrote:
> Richard B. Gilbert wrote:
> 
>> There is little reason to write anything in Macro today; device drivers 
>> can be written in C.  What else was Macro good for?
> 
> 
> Making transfer vectors for sharable images ? Are there now tools to
> make those without Macro ?

Don't know!  Don't recall ever doing that!

Glen Herrmannsfeldt wrote:
> Tim E. Sneddon wrote:
> (snip)
> 
>> Anyone who *willingly* chooses Itanium assembly to write anything
>> should immediately get themselves to a doctor!
> 
> VAX is probably one of the easier assembly languages to learn.
> 
> PDP-11 and S/360 also aren't so bad.
> 
> I haven't tried Itanium yet, and I don't know that I want to,
> but I will soon have one to try it on.
> 
> -- glen
> 

Assembler language programming is just about dead.  The only time it's 
really necessary is when you are bootstrapping a new hardware platform. 
  Even device drivers are now written in C.

It's just too damned expensive to program in assembler!

Richard B. Gilbert schrieb:

> 
> Assembler language programming is just about dead.  The only time it's 
> really necessary is when you are bootstrapping a new hardware platform. 
>  Even device drivers are now written in C.

Not every CPU instruction has an equivalent HL construct.
Think of byte swapping or "compare & swap" and friends.

> It's just too damned expensive to program in assembler!

But it can be fun, sometimes.

Richard B. Gilbert wrote:

> Assembler language programming is just about dead.  The only time it's 
> really necessary is when you are bootstrapping a new hardware platform. 
>  Even device drivers are now written in C.

> It's just too damned expensive to program in assembler!

I mostly do things that you can't do in high-level
language, but as little as possible.  My favorite is an
assembler routine to return the IA32 time stamp counter.

         .file   "rdtsc.f"
         .text
         .p2align 4,,15
..globl rdtsc_
         .type   rdtsc_, @function
rdtsc_:
         rdtsc
         ret
         .size   rdtsc_, .-rdtsc_

There are only two executable instructions.

Most of the other lines probably aren't needed, but I wrote
a function in Fortran, compiled it with -S, removed the unneeded
instructions and put in the rdtsc.

Also, being able to read assembler is useful for reading
the output of the compilers (with -S) even if you don't actually
write any.

-- glen

The request came about because of an interest in participating in the
retrochallenge contest: examples of this years entries can be found at
http://retrochallenge.net/2008

The idea is to spend a month (as much or as little time as you fancy) on
a project related to old hardware or software. Apologies, I don't mean
to offend anyone who still works with the kind of technologies I am
talking about - but to me the last time I did some real MACRO-32
programming was my first job out of college in 1991 - so to me the
technology is old!

I have done bits and pieces of MC68K which I also used in earlier days -
in this case I don't consider it so 'old' as there still microprocessors
being sold for new development in the Freescale Coldfire product range.
Admittedly the vast majority of code will be written in C, but that's
not to say that dropping down to assembler is not the right thing to do
on occassion. "Best language for the job" always prevails.

So I was thinking of immersing myself in a small project for a month
purely out of interest.

The other train of thought out of this was to try and tease out of some
of you any development environments or languages that have struck you as
elegant, pleasant and productive. I know of Ruby, Python seems pretty
good, and Tk/Tcl pop up regularly. Any I've overlooked. What is the
modern day enquivalent of Visual Basic. I'm not thinking here so much
about the language as of an IDE that allows an application with a GUI to
be assembled quickly. Does such a tool exist for screen-oriented
character applications?

Regards, Mark.

Mark Wickens wrote:
> The request came about because of an interest in participating in the
> retrochallenge contest: examples of this years entries can be found at
> http://retrochallenge.net/2008
> 
> The idea is to spend a month (as much or as little time as you fancy) on
> a project related to old hardware or software. Apologies, I don't mean
> to offend anyone who still works with the kind of technologies I am
> talking about - but to me the last time I did some real MACRO-32
> programming was my first job out of college in 1991 - so to me the
> technology is old!
> 
> I have done bits and pieces of MC68K which I also used in earlier days -
> in this case I don't consider it so 'old' as there still microprocessors
> being sold for new development in the Freescale Coldfire product range.
> Admittedly the vast majority of code will be written in C, but that's
> not to say that dropping down to assembler is not the right thing to do
> on occassion. "Best language for the job" always prevails.
> 
> So I was thinking of immersing myself in a small project for a month
> purely out of interest.
> 
> The other train of thought out of this was to try and tease out of some
> of you any development environments or languages that have struck you as
> elegant, pleasant and productive. I know of Ruby, Python seems pretty
> good,...

I've used Python on VMS some.

It's a nice package with a lot of "modules" pre-installed
read-to-be-used. Just the other day I wrote a short Python
script (20-30 lines of Python code) that reads out a Rdb
table and creates an PDF document with data from the
table tabulated both as text and in Code39. It uses the
builtin Rdb interface and a module called "ReportLab"
to create the PDF.


> and Tk/Tcl pop up regularly. Any I've overlooked. What is the
> modern day enquivalent of Visual Basic. I'm not thinking here so much
> about the language as of an IDE that allows an application with a GUI to
> be assembled quickly. Does such a tool exist for screen-oriented
> character applications?

The VMS/Python kit mentioned above has a built-in interface
against the SMG$ (Screen Management) routines in VMS. That
is, you program your screens "Python-style".

Jan-Erik.

> 
> Regards, Mark.

 > Anyone who *willingly* chooses Itanium assembly to write anything
 > should immediately get themselves to a doctor!

Well, then it's time for me to see a doctor.... and soon!

I'm working on an application generating native itanium code on
the fly (running on VMS), so I play for compiler myself. Lots of fun.... :-)

Jur.

Tim E. Sneddon wrote, On 27-11-2008 0:38:
> John Reagan wrote:
>> "Mark Wickens" <mark@wickensonline.co.uk> wrote in message 
>> news:ggk8j0$gpo$1@news.motzarella.org...
>>> This is purely an academic exercise - I am doing my 'learn one language
>>> a year' and this year it is MACRO-32.
>>
>> Not to discourage you, but honestly why learn the instruction set of a 
>> computer from the 1970's which isn't even made anymore?
>>
>> At least do X86 or Itanium assembly if you must satisify some urge to 
>> twiddle bits.
>>
> 
> Anyone who *willingly* chooses Itanium assembly to write anything
> should immediately get themselves to a doctor!
> 
> Tim.

In article <gglpbp$7r5$1@news.motzarella.org>, Mark Wickens
<mark@wickensonline.co.uk> writes:
> 
> I have done bits and pieces of MC68K which I also used in earlier days -
> in this case I don't consider it so 'old' as there still microprocessors
> being sold for new development in the Freescale Coldfire product range.

I think even the original 68K chips (68000 through 68060) are still
being made and sold. At least they weren't EOLed last time I checked,
about half a year ago. 

> Admittedly the vast majority of code will be written in C, but that's
> not to say that dropping down to assembler is not the right thing to do
> on occassion. "Best language for the job" always prevails.

Assembly on 68K is almost like C.
 

Michael Kraemer wrote:

> In article <gglpbp$7r5$1@news.motzarella.org>, Mark Wickens
> <mark@wickensonline.co.uk> writes:
>> 
>> I have done bits and pieces of MC68K which I also used in earlier days -
>> in this case I don't consider it so 'old' as there still microprocessors
>> being sold for new development in the Freescale Coldfire product range.
> 
> I think even the original 68K chips (68000 through 68060) are still
> being made and sold. At least they weren't EOLed last time I checked,
> about half a year ago.
> 
>> Admittedly the vast majority of code will be written in C, but that's
>> not to say that dropping down to assembler is not the right thing to do
>> on occassion. "Best language for the job" always prevails.
> 
> Assembly on 68K is almost like C.

Eh ? Does this (one of the few things I wrote in m68K assembly language),
look like C ?

Bus_Trap_Handle:  
        move.l  d0,Bus_Trap_Mode(a6)    ;handling mode of bus-/address-traps
        move.l  d1,Bus_Trap_Access_Mode(a6) ;mode of bus-access       
        movem.l d1/a0-a1,-(a7) 
        clr.l   d0 
        movea.l d0,a0           
        lea     exc_table(pc),a1       
        os9     F$STrap         
        bcc.b   ih99
        move.l  d1,errno(a6)   
        move.l  #-1,d0 
ih99    movem.l (a7)+,d1/a0-a1
        rts  

It looks more like VAX (Makro-)assembler !

--
Joseph Huber, http://www.huber-joseph.de

In article <0019f8d3$0$12352$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>Richard B. Gilbert wrote:
>
>> There is little reason to write anything in Macro today; device drivers 
>> can be written in C.  What else was Macro good for?
>
>
>Making transfer vectors for sharable images ? Are there now tools to
>make those without Macro ?

Yeah, it's called the LINKER OPTION file.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.

Michael Kraemer wrote:
> Richard B. Gilbert schrieb:
> 
>>
>> Assembler language programming is just about dead.  The only time it's 
>> really necessary is when you are bootstrapping a new hardware 
>> platform.  Even device drivers are now written in C.
> 
> Not every CPU instruction has an equivalent HL construct.
> Think of byte swapping or "compare & swap" and friends.
> 
>> It's just too damned expensive to program in assembler!
> 
> But it can be fun, sometimes.
> 

I know!   I used to enjoy it.  The world moved on and the Pointy Haired 
Bosses wanted it done on time.  It didn't matter if it didn't always 
work as long as it was on time!

VAXman- @SendSpamHere.ORG wrote:

>>Making transfer vectors for sharable images ? Are there now tools to
>>make those without Macro ?
> 
> Yeah, it's called the LINKER OPTION file.

Do you have an example of a way to build a transfer vector with the linker ?

I was under the impression that the linker simply built the table of
entry points which was not garanteed to be the same if you changed your
code around. So your chareable image would work with
LIB$FIND_IMAGE_SYMBOL since this was dynamic linking to a shareable
image, but not necessarily with conventional shareable images that have
fixed links resolved at link time, not at run time.

On Nov 27, 4:11=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> VAXman- @SendSpamHere.ORG wrote:
> >>Making transfer vectors for sharable images ? Are there now tools to
> >>make those without Macro ?
>
> > Yeah, it's called the LINKER OPTION file.
>
> Do you have an example of a way to build a transfer vector with the linke=
r ?
>
> I was under the impression that the linker simply built the table of
> entry points which was not garanteed to be the same if you changed your
> code around. So your chareable image would work with
> LIB$FIND_IMAGE_SYMBOL since this was dynamic linking to a shareable
> image, but not necessarily with conventional shareable images that have
> fixed links resolved at link time, not at run time.


See the fine manual - its different on itanium

On Nov 27, 12:33=A0pm, Joseph Huber <joseph.hu...@NOSPAM.web.de> wrote:
> Michael Kraemer wrote:
> > In article <gglpbp$7r...@news.motzarella.org>, Mark Wickens
> > <m...@wickensonline.co.uk> writes:
>
> >> I have done bits and pieces of MC68K which I also used in earlier days=
 -
> >> in this case I don't consider it so 'old' as there still microprocesso=
rs
> >> being sold for new development in the Freescale Coldfire product range=
..
>
> > I think even the original 68K chips (68000 through 68060) are still
> > being made and sold. At least they weren't EOLed last time I checked,
> > about half a year ago.
>
> >> Admittedly the vast majority of code will be written in C, but that's
> >> not to say that dropping down to assembler is not the right thing to d=
o
> >> on occassion. "Best language for the job" always prevails.
>
> > Assembly on 68K is almost like C.
>
> Eh ? Does this (one of the few things I wrote in m68K assembly language),
> look like C ?
>
> Bus_Trap_Handle: =A0
> =A0 =A0 =A0 =A0 move.l =A0d0,Bus_Trap_Mode(a6) =A0 =A0;handling mode of b=
us-/address-traps
> =A0 =A0 =A0 =A0 move.l =A0d1,Bus_Trap_Access_Mode(a6) ;mode of bus-access=
 =A0 =A0 =A0
> =A0 =A0 =A0 =A0 movem.l d1/a0-a1,-(a7)
> =A0 =A0 =A0 =A0 clr.l =A0 d0
> =A0 =A0 =A0 =A0 movea.l d0,a0 =A0 =A0 =A0 =A0 =A0
> =A0 =A0 =A0 =A0 lea =A0 =A0 exc_table(pc),a1 =A0 =A0 =A0
> =A0 =A0 =A0 =A0 os9 =A0 =A0 F$STrap =A0 =A0 =A0 =A0
> =A0 =A0 =A0 =A0 bcc.b =A0 ih99
> =A0 =A0 =A0 =A0 move.l =A0d1,errno(a6) =A0
> =A0 =A0 =A0 =A0 move.l =A0#-1,d0
> ih99 =A0 =A0movem.l (a7)+,d1/a0-a1
> =A0 =A0 =A0 =A0 rts =A0
>
> It looks more like VAX (Makro-)assembler !
>
> --
> Joseph Huber,http://www.huber-joseph.de

It is an allegedly well known fact that much of C was inspired by
PDP11 assembly, opcodes, and addressing modes, and at first glance it
seems plausible. However, I'm not sure I believe it as (a) I think
I've read an interview (with Dennis Ritchie?, who may perhaps be
considered definitive) which claims there's no truth to it, though I
can't remember where I read it (b) you can subtract two bytes in C and
you can't (trivially) subtract bytes on a PDP11, even though most
other popular PDP11 instructions had byte variants where applicable.
More details on the PDP11 Programmers Card at e.g.
http://www.jfc.org.uk/documents/scandoc.php?page=3D2&maxpage=3D10%0A&dir=3D=
pdp11%2Fpdp11.

I too am surprised to see Motorola 68K assembler described as C-like.
It could perhaps have been, if they wanted to, given that C arrived a
few years before M68K. But afaict it wasn't.

johnwallace4@yahoo.co.uk wrote:

> It is an allegedly well known fact that much of C was inspired by
> PDP11 assembly, opcodes, and addressing modes, and at first glance it
> seems plausible.


Kerningham-Ritchie (in the C book) confirm that C was first written on a
PDP-11 running Unix.

The availability of certain assembler operators in the PDP-11 may have
made it easy to implement certain operations and thus made it into early
release of C. For instance, if there is a bit shift assembler operator,
it makes it easy to implement the C bitshift operator.

However, the functions that are native to C are pretty basic and would
exist (or easily implemented) in any architecture. If the architecture
doesn't have a bitshift operator, you then generate a few instructions
that set the high order bit to 0, multiply the number by 2 and you have
your shift left.

C was meant to be platform independant.

johnwallace4@yahoo.co.uk writes:

>On Nov 27, 12:33=A0pm, Joseph Huber <joseph.hu...@NOSPAM.web.de> wrote:

>It is an allegedly well known fact that much of C was inspired by
>PDP11 assembly, opcodes, and addressing modes, and at first glance it
>seems plausible. However, I'm not sure I believe it as (a) I think
>I've read an interview (with Dennis Ritchie?, who may perhaps be
>considered definitive) which claims there's no truth to it, though I
>can't remember where I read it (b) you can subtract two bytes in C and
>you can't (trivially) subtract bytes on a PDP11, even though most
>other popular PDP11 instructions had byte variants where applicable.

I would disregard b).  While it's true there is such a restriction
in the PDP-11 instruction set, someone writing a compiler would see no
reason to have to live by the PDP-11's instruction limitations, they know
people will want to subtract bytes (chars) sometimes, and make the 
compiler generate code equivalent to byte subtraction, even if it can't
be one instruction.

>I too am surprised to see Motorola 68K assembler described as C-like.
>It could perhaps have been, if they wanted to, given that C arrived a
>few years before M68K. But afaict it wasn't.

I've heard that the 68K instruction set was inspired by the PDP-11's
instruction set.

JF Mezei wrote:
> johnwallace4@yahoo.co.uk wrote:
> 
>> It is an allegedly well known fact that much of C was inspired by
>> PDP11 assembly, opcodes, and addressing modes, and at first glance it
>> seems plausible.
> 
> 
> Kerningham-Ritchie (in the C book) confirm that C was first written on a
> PDP-11 running Unix.

Who?????????????

Perhaps you meant Kernighan & Ritchie?

On Nov 27, 8:43=A0pm, moro...@world.std.spaamtrap.com (Michael Moroney)
wrote:
> johnwalla...@yahoo.co.uk writes:
> >On Nov 27, 12:33=3DA0pm, Joseph Huber <joseph.hu...@NOSPAM.web.de> wrote=
:
> >It is an allegedly well known fact that much of C was inspired by
> >PDP11 assembly, opcodes, and addressing modes, and at first glance it
> >seems plausible. However, I'm not sure I believe it as (a) I think
> >I've read an interview (with Dennis Ritchie?, who may perhaps be
> >considered definitive) which claims there's no truth to it, though I
> >can't remember where I read it (b) you can subtract two bytes in C and
> >you can't (trivially) subtract bytes on a PDP11, even though most
> >other popular PDP11 instructions had byte variants where applicable.
>
> I would disregard b). =A0While it's true there is such a restriction
> in the PDP-11 instruction set, someone writing a compiler would see no
> reason to have to live by the PDP-11's instruction limitations, they know
> people will want to subtract bytes (chars) sometimes, and make the
> compiler generate code equivalent to byte subtraction, even if it can't
> be one instruction.
>
> >I too am surprised to see Motorola 68K assembler described as C-like.
> >It could perhaps have been, if they wanted to, given that C arrived a
> >few years before M68K. But afaict it wasn't.
>
> I've heard that the 68K instruction set was inspired by the PDP-11's
> instruction set.
..
The reference to PDP11 missing ADDB/SUBB instructions wasn't meant to
be taken entirely seriously. Sorry. Maybe there aren't as many PDP11
folks around here as I hoped...

I was reasonably familiar with both PDP11 and M68K (and 6800 and 6809
and 9900 and Z8000 and even NS16000 at one time, not to mention
various Intel things including iAPX432) and there's not really much
commonality between PDP instruction set and addressing modes and M68K
instruction modes. One thing the PDP11 and 68K did both have in common
was that IO didn't have its own specific instructions or its own
address space, unlike some others which had specific IO instructions
and a separate IO address space. Now if you'd said the National
Semiconductor NS16000 had been inspired by VAX with the additional
design goals of modernisation, removal of cruft, and simple support
for ROMable code, I'd have agreed with that. But very few folks ever
heard of the NS16000 and it sank without trace. Well, HP eventually
named an Integrity server after it, but...

Meanwhile, back to Mr Ritchie. I can't find the interview I thought I
read, but just as JF says, the frontmatter in K+R says "C was
originally designed for and implemented on the UNIX operating system
on the DEC PDP-11, by Dennis Ritchie." (see
http://www.amazon.com/gp/reader/0131103709/ref=3Dsib_dp_pt#reader-link).
Ritchie's own in-depth story of the development of the C programming
language provides a lot more background and doesn't really say C was
originally designed for PDP11, though PDP11 seems to have been the
first implementation: http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

Times change though. I'm just in the process of writing my first
device driver for an ARM (IXP425) machine (running Linux). I currently
have absolutely no idea what the instruction set looks like, and
ideally it'll stay that way, but...

On Thu, 27 Nov 2008 22:44:26 UTC, johnwallace4@yahoo.co.uk wrote:

> The reference to PDP11 missing ADDB/SUBB instructions wasn't meant to
> be taken entirely seriously. Sorry. Maybe there aren't as many PDP11
> folks around here as I hoped...

I programmed PDP-11 stuff for years, and never actually noticed the lack
of a byte subtract...! Never needed it I guess... I may have been too 
ashamed to say so earlier...

> I was reasonably familiar with both PDP11 and M68K (and 6800 and 6809
> and 9900 and Z8000 and even NS16000 at one time, not to mention
> various Intel things including iAPX432) and there's not really much
> commonality between PDP instruction set and addressing modes and M68K
> instruction modes. One thing the PDP11 and 68K did both have in common
> was that IO didn't have its own specific instructions or its own
> address space, unlike some others which had specific IO instructions
> and a separate IO address space.

And (originally) the memory alignment trap..!

> Meanwhile, back to Mr Ritchie. I can't find the interview I thought I
> read, but just as JF says, the frontmatter in K+R says "C was
> originally designed for and implemented on the UNIX operating system
> on the DEC PDP-11, by Dennis Ritchie." (see
> http://www.amazon.com/gp/reader/0131103709/ref=sib_dp_pt#reader-link).

Or just pull it off the shelf, in my case!

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

Jan-Erik S�derholm wrote:
> Mark Wickens wrote:
>> The other train of thought out of this was to try and tease out of some
>> of you any development environments or languages that have struck you as
>> elegant, pleasant and productive. I know of Ruby, Python seems pretty
>> good,...
> 
> I've used Python on VMS some.
> 
> It's a nice package with a lot of "modules" pre-installed
> read-to-be-used. Just the other day I wrote a short Python
> script (20-30 lines of Python code) that reads out a Rdb
> table and creates an PDF document with data from the
> table tabulated both as text and in Code39. It uses the
> builtin Rdb interface and a module called "ReportLab"
> to create the PDF.

Python is a nice language.

Good combination of powerful and easy to write.

It is recommendable.

I have never used it on VMS though.

Arne

Richard B. Gilbert wrote:
> Glen Herrmannsfeldt wrote:
>> Tim E. Sneddon wrote:
>> (snip)
>>
>>> Anyone who *willingly* chooses Itanium assembly to write anything
>>> should immediately get themselves to a doctor!
>>
>> VAX is probably one of the easier assembly languages to learn.
>>
>> PDP-11 and S/360 also aren't so bad.
>>
>> I haven't tried Itanium yet, and I don't know that I want to,
>> but I will soon have one to try it on.
> 
> Assembler language programming is just about dead.  The only time it's 
> really necessary is when you are bootstrapping a new hardware platform. 
>  Even device drivers are now written in C.
> 
> It's just too damned expensive to program in assembler!

As a general programming languages - yes.

You can still need it for using some special instructions
not available in HLL.

Oh - and it is still a good thing to learn at least one
assembler to get a good understanding of how code executes.

(and obviously compiler backend writers need to understand
the instruction set very well)

Arne

In article <e8181bcc-65a6-4aa1-967b-5205afc2fc75@j32g2000yqn.googlegroups.com>, IanMiller <gxys@uk2.net> writes:
>On Nov 27, 4:11=A0pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
>> VAXman- @SendSpamHere.ORG wrote:
>> >>Making transfer vectors for sharable images ? Are there now tools to
>> >>make those without Macro ?
>>
>> > Yeah, it's called the LINKER OPTION file.
>>
>> Do you have an example of a way to build a transfer vector with the linke=
>r ?
>>
>> I was under the impression that the linker simply built the table of
>> entry points which was not garanteed to be the same if you changed your
>> code around. So your chareable image would work with
>> LIB$FIND_IMAGE_SYMBOL since this was dynamic linking to a shareable
>> image, but not necessarily with conventional shareable images that have
>> fixed links resolved at link time, not at run time.
>
>
>See the fine manual - its different on itanium

What's different?

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.

Arne Vajh�j wrote:
> Richard B. Gilbert wrote:
>> Glen Herrmannsfeldt wrote:
>>> Tim E. Sneddon wrote:
>>> (snip)
>>>
>>>> Anyone who *willingly* chooses Itanium assembly to write anything
>>>> should immediately get themselves to a doctor!
>>>
>>> VAX is probably one of the easier assembly languages to learn.
>>>
>>> PDP-11 and S/360 also aren't so bad.
>>>
>>> I haven't tried Itanium yet, and I don't know that I want to,
>>> but I will soon have one to try it on.
>>
>> Assembler language programming is just about dead.  The only time it's 
>> really necessary is when you are bootstrapping a new hardware 
>> platform.  Even device drivers are now written in C.
>>
>> It's just too damned expensive to program in assembler!
> 
> As a general programming languages - yes.
> 
> You can still need it for using some special instructions
> not available in HLL.
> 
> Oh - and it is still a good thing to learn at least one
> assembler to get a good understanding of how code executes.
> 
> (and obviously compiler backend writers need to understand
> the instruction set very well)
> 
> Arne

I think I have used nine different assembler languages in my career.

SDS-930, IBM System/360, IBM System/7, H-P 21MXE, PDP-8, PDP-11, VAX, 
80x86 and Z80 for sure.  For some of that hardware, assembler was the 
ONLY choice!

On 2008-11-27, johnwallace4@yahoo.co.uk <johnwallace4@yahoo.co.uk> wrote:
> Now if you'd said the National
> Semiconductor NS16000 had been inspired by VAX with the additional
> design goals of modernisation, removal of cruft, and simple support
> for ROMable code, I'd have agreed with that.

Pfft. I've never understood how people can say that when the NS16000
doesn't even have the PC as a general-purpose register. 
-- 
roger ivie
rivie@ridgenet.net

JF Mezei wrote:
> johnwallace4@yahoo.co.uk wrote:

>>It is an allegedly well known fact that much of C was inspired by
>>PDP11 assembly, opcodes, and addressing modes, and at first glance it
>>seems plausible.

> Kerningham-Ritchie (in the C book) confirm that C was first
> written on a PDP-11 running Unix.

Yes, but C descended from BCPL and B, which were older
than the PDP-11.

> The availability of certain assembler operators in the PDP-11 may have
> made it easy to implement certain operations and thus made it into early
> release of C. For instance, if there is a bit shift assembler operator,
> it makes it easy to implement the C bitshift operator.

Bitshift has been around for a while, in both hardware and
other high-level languages (though not always part of the
language standard).  It is the increment and decrement operators
that are sometimes connected to the PDP-11.  The story seems to
be that there is no causal connection from the PDP-11 to C
operators.

> However, the functions that are native to C are pretty basic and would
> exist (or easily implemented) in any architecture. If the architecture
> doesn't have a bitshift operator, you then generate a few instructions
> that set the high order bit to 0, multiply the number by 2 and you have
> your shift left.

Bitshift operators go pretty far back in the history of
binary computers.  The autoincrement and autodecrement
address modes of the PDP-11 were less common.  (Though I
believe that there were earlier machines with autoincrement
memory locations.)

> C was meant to be platform independant.

Yes.  Among others, note that using the shift operators with
the shift amount greater than or equal to the word length is undefined.

Also, the rounding when dividing negative numbers.

-- glen

On Fri, 28 Nov 2008 00:53:28 UTC, "Richard B. Gilbert" 
<rgilbert88@comcast.net> wrote:

> I think I have used nine different assembler languages in my career.
> 
> SDS-930, IBM System/360, IBM System/7, H-P 21MXE, PDP-8, PDP-11, VAX, 
> 80x86 and Z80 for sure.  For some of that hardware, assembler was the 
> ONLY choice!

Same here...there was little option. Let's see... ICL 4130, Honeywell 
516, ICL 1900, DECSystem-10, PDP-8, ICL 2900, PDP-11, VAX, x86, IBM 370,
8085, Z80, MC68000 are the first ones that come to mind (that's 13!). 
There are probably others I've forgotten...
-- 
Bob Eager
Use the BIG mirror service in the UK:
http://www.mirrorservice.org

On Nov 26, 7:05=A0pm, "Richard B. Gilbert" <rgilber...@comcast.net>
wrote:
> Arne Vajh=F8j wrote:
> > Mark Wickens wrote:
> >> Jan-Erik S=F6derholm wrote:
> >>> I can't help to ask, why ?
> >>> Why write an "application" (whatever that is) in MACRO ?
>
> >> Thanks for the replies - yes asking 'why' is a good question.
>
> >> This is purely an academic exercise - I am doing my 'learn one languag=
e
> >> a year' and this year it is MACRO-32.
>
> > If you want to code in assembler, then Macro-32 is probably one
> > of the easiest instruction sets to code in - its CISC'ness
> > makes it much easier that anything else I have tried.
>
> > But note that VAX'es stopped being produced in the mid 90's.
>
> But note that, given the proper software, you can compile VAX Macro to
> produce Alpha object code. =A0I wouldn't be surprised if this could also
> be done on Itanic.
>
> ISTR doing this once nine or ten years ago. =A0I had some useful snippet
> written in macro and wanted to use it on Alpha. . . .
>
> There is little reason to write anything in Macro today; device drivers
> can be written in C. =A0What else was Macro good for?
>
> The days when the ability to hand optimize code was useful are long gone
> along with the machines on which hand optimization could make a
> significant difference!

Correct. Unless you are attending a college course titled "ancient
programming tools from the CISC era", C is a much better choice.
Sometimes "C" is even a better choice for CISC projects.

Twenty years ago I was doing some contract work for a local
manufacturer. I started the 68hc11 project using a macro-assember but
it turned out that I was the only person with the skills to maintain
it. Others convinced me to switch to a higher level language. They
wanted BASIC but there was nothing available at that time to meet our
needs so I went with Intermetrics "C" (now called COSMIC-C). It took
about a week to rewrite all the code (there were lots of interrupt
handlers etc. and this was an embedded app without any micro OS),  The
resultant "C" code was child's play to extend and maintain.

Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/links/openvms_demos.html

> "Good example in C" I would suggest is an oxymoron.

C is a language that combines the power and flexibility of assembler 
with the readability and ease of use of assembler.

---------------------------------------------------------
Tom Wade                 | EMail: tee dot wade at eurokom dot ie
EuroKom                  | Tel:   +353 (1) 296-9696
A2, Nutgrove Office Park | Fax:   +353 (1) 296-9697
Rathfarnham              | Disclaimer:  This is not a disclaimer
Dublin 14                | Tip:   "Friends don't let friends do Unix !"
Ireland

On Nov 28, 12:54 am, Roger Ivie <ri...@ridgenet.net> wrote:
> On 2008-11-27, johnwalla...@yahoo.co.uk <johnwalla...@yahoo.co.uk> wrote:
>
> > Now if you'd said the National
> > Semiconductor NS16000 had been inspired by VAX with the additional
> > design goals of modernisation, removal of cruft, and simple support
> > for ROMable code, I'd have agreed with that.
>
> Pfft. I've never understood how people can say that when the NS16000
> doesn't even have the PC as a general-purpose register.
> --
> roger ivie
> ri...@ridgenet.net

NS16000 wasn't a VAX clone (the Russians did those, right?), it wasn't
even trying to be VAX compatible, but chunks of it might well have
been VAX-inspired. Anyway, if you can still achieve all the relevant
addressing modes using PC-relative addressing, module pointers, etc,
which iirc the NS16000 could, what do you actually lose by not having
the PC as a general register? (or is it my turn for a sense of humour
failure?) Obviously you can't do the usual party tricks like MOV -
(R7), -(R7) like some PDP11s could, but so what? Anyway, history has
shown that a nice instruction set architecture is not necessarily
guarantee of, or even a prerequisite for, market success. Not then,
not now.

I think Ritchie's in-depth history of C (http://cm.bell-labs.com/cm/cs/
who/dmr/chist.html) says the auto-increment/auto-decrement stuff came
from PDP7.

One thing I like about C vs C++ is that the C language itself is
relatively small; sufficiently small that the number of times I have
to look something up, to see what the syntax is, is (for me, in the
areas in which I work) small to negligible (hence, although I no
longer have either of my copies of K+R, I do not feel lost without
them). In comparison, the C++ language and associated guff is so big
that no normal person can be expected to remember much of it, and
unless you're doing it full time, big bits of the required knowledge
get swapped out. Horses for courses, maybe.

Has the original author actually said what kind of problem he's
interested in solving? Python looks quite interesting for some classes
of problem, not that I've actually used it yet.

On Thu, 27 Nov 2008 16:54:11 -0800, Roger Ivie <rivie@ridgenet.net> wrote:

> On 2008-11-27, johnwallace4@yahoo.co.uk <johnwallace4@yahoo.co.uk> wrote:
>> Now if you'd said the National
>> Semiconductor NS16000 had been inspired by VAX with the additional
>> design goals of modernisation, removal of cruft, and simple support
>> for ROMable code, I'd have agreed with that.
>
> Pfft. I've never understood how people can say that when the NS16000
> doesn't even have the PC as a general-purpose register.

The NS16032 instruction was mainly inspired by the VAX.  The PC was not
in a general register owing to a DEC patent on same.  I ported Unix and
did PL/I, Fortan and Pascal for that device.

-- 
PL/I for OpenVMS
www.kednos.com

Tom Wade wrote:
>> "Good example in C" I would suggest is an oxymoron.
> 
> C is a language that combines the power and flexibility of assembler 
> with the readability and ease of use of assembler.

Even if it is a joke, then it has some foundation in reality. It
is not possible to create a language that gives you full flexibility
to do the tricks you want and still prevent you from doing mistakes.
Either you have the cake or you eat it.

Arne

Arne Vajh�j wrote:
> Tom Wade wrote:
>>> "Good example in C" I would suggest is an oxymoron.
>>
>> C is a language that combines the power and flexibility of assembler 
>> with the readability and ease of use of assembler.
> 
> Even if it is a joke, then it has some foundation in reality. It
> is not possible to create a language that gives you full flexibility
> to do the tricks you want and still prevent you from doing mistakes.
> Either you have the cake or you eat it.
> 

The answer is the legendary DWIM!  (Do What I Mean)  The guy who writes 
it will be able to buy and sell Bill Gates.

On Fri, 28 Nov 2008 08:16:25 -0800, Arne Vajh�j <arne@vajhoej.dk> wrote:

> Tom Wade wrote:
>>> "Good example in C" I would suggest is an oxymoron.
>>  C is a language that combines the power and flexibility of assembler  
>> with the readability and ease of use of assembler.
>
> Even if it is a joke, then it has some foundation in reality. It
> is not possible to create a language that gives you full flexibility
> to do the tricks you want and still prevent you from doing mistakes.
> Either you have the cake or you eat it.
>
> Arne

Some cakes are tastier than others.


-- 
PL/I for OpenVMS
www.kednos.com

Tom Linden wrote:
> On Fri, 28 Nov 2008 08:16:25 -0800, Arne Vajh�j <arne@vajhoej.dk> wrote:
>> Tom Wade wrote:
>>>> "Good example in C" I would suggest is an oxymoron.
>>>  C is a language that combines the power and flexibility of assembler 
>>> with the readability and ease of use of assembler.
>>
>> Even if it is a joke, then it has some foundation in reality. It
>> is not possible to create a language that gives you full flexibility
>> to do the tricks you want and still prevent you from doing mistakes.
>> Either you have the cake or you eat it.
> 
> Some cakes are tastier than others.

We all know that you prefer [BCDFGHJKLMNPQRSTWVXZ]{2}/[AEIOUY]{1}
cakes.

:-)

Arne

Neil Rieck wrote:
> Correct. Unless you are attending a college course titled "ancient
> programming tools from the CISC era", C is a much better choice.
> Sometimes "C" is even a better choice for CISC projects.

CISC seems to be living very well.

I don't think Intel and AMD are that scared by PPC, SPARC and IA-64.

Arne

On Nov 26, 1:38=A0pm, Mark Wickens <m...@wickensonline.co.uk> wrote:
> Jan-Erik S=F6derholm wrote:
> > =A0On Nov 26, 4:39 pm, Mark Wickens <m...@wickensonline.co.uk> wrote:
> >> Hi,
>
> >> Could anyone suggest a program with a decent amount of C and MACRO cod=
e?
> >> =A0I'm also after suggestions as to what library I should use to write=
 a
> >> character-terminal screen based application in C/MACRO.
>
> >> Thanks for the help,
>
> >> Mark.
>
> > I can't help to ask, why ?
> > Why write an "application" (whatever that is) in MACRO ?
>
> > And, as have said, a lot of the VMS freeware tools are
> > probably written in MACRO and/or C.
>
> Thanks for the replies - yes asking 'why' is a good question.
>
> This is purely an academic exercise - I am doing my 'learn one language
> a year' and this year it is MACRO-32. I have done more than my fair
> share of C programming, but I'm now entrenched in the Java/Web
> programming arena. As programming for the internet is my day job I
> wanted a suitably different scenario to 'play' with.
>
> To be honest I'm pretty sick of web programming. It would be hard to
> think of a more clunky way of providing a minimal level of user
> interaction. I've investigated a number of options, the most pure of
> which appears to be google web toolkit (pure-java based solution that
> autogenerates the required client side javascript) but they're all
> horrible - either everything happens in one window (so page
> navigation/bookmarking doesn't work) or every interaction must fit into
> the web 'page-at-a-time' cycle. Bolt on functionality that would be
> integral to any decent application development environment has to be
> performed using highly browser-dependent javascript (don't even get me
> started with that!)
>
> I've done Java Swing programming before which is where the 'application'
> part of the requirement comes into it. More flexible interaction is
> great and entirely possible, but at the cost of increased complexity.
>
> I'd welcome anyones experience of application development using other
> tools and languages. I find that most of the people I work with now have
> a very narrowly-focused mindset based exclusively around web development.
>
> I looked at character-based application toolkits, and just decided that
> as I have no 'run-everywhere' requirement I would concentrate on
> developing for a platform and toolset which is stable and reliable -
> OpenVMS. In that sense I would like to broker people's opinions on the
> 'nicest' screen-oriented library available for the platform. I've come
> across ncurses before and wondered if any of the VMS-specific libraries
> offer a more pleasant development experience.
>
> Kind regards,
>
> Mark.

Pleasant development would be FMS.  There are lots of examples on how
to use it.

If you are looking for something "interesting" to do, why don't you
look into porting the opensource Qt library to OpenVMS?  All of the
source code is out there.

If that is a bit much, you could look into reserecting the OpenVMS
code in Postgresql.  Yes, it originally ran on VAX/VMS.

On Nov 26, 5:38=A0pm, "Tim E. Sneddon" <tesned...@bigpond.com> wrote:
> John Reagan wrote:
> > "Mark Wickens" <m...@wickensonline.co.uk> wrote in message
> >news:ggk8j0$gpo$1@news.motzarella.org...
> >> This is purely an academic exercise - I am doing my 'learn one languag=
e
> >> a year' and this year it is MACRO-32.
>
> > Not to discourage you, but honestly why learn the instruction set of a
> > computer from the 1970's which isn't even made anymore?
>
> > At least do X86 or Itanium assembly if you must satisify some urge to
> > twiddle bits.
>
> Anyone who *willingly* chooses Itanium assembly to write anything
> should immediately get themselves to a doctor!
>
> Tim.


Anyone who *willingly* chooses an Itanium boat anchor should get
themselves to a doctor.

"JF Mezei" <jfmezei.spamnot@vaxination.ca> wrote in message 
news:0019f8d3$0$12352$c3e8da3@news.astraweb.com...
> Richard B. Gilbert wrote:
>
>> There is little reason to write anything in Macro today; device drivers
>> can be written in C.  What else was Macro good for?
>
>
> Making transfer vectors for sharable images ? Are there now tools to
> make those without Macro ?

You haven't need Macro to create transfer vectors since VAX.  Replaced with 
SYMBOL_VECTOR in the LINKER options file on Alpha and I64.

John 

"Jur van der Burg" <"lddriver at digiater dot nl"> wrote in message 
news:492e8d19$0$197$e4fe514c@news.xs4all.nl...
> > Anyone who *willingly* chooses Itanium assembly to write anything
> > should immediately get themselves to a doctor!
>
> Well, then it's time for me to see a doctor.... and soon!
>
> I'm working on an application generating native itanium code on
> the fly (running on VMS), so I play for compiler myself. Lots of fun.... 
> :-)
>

Code on the fly?  You are in for a whole bunch of fun.  Besides figuring out 
template, stop-bits, computing bundle-relative offsets, you'll also have to 
create unwind descriptors (also on the fly) and register them with the 
appropriate system service.  And you're doing this in elevated mode, there 
is more fun to make sure the unwind descriptors are unmapped at the right 
times.

John 

"Michael Kraemer" <M.Kraemer@gsi.de> wrote in message 
news:ggljto$85k$00$2@news.t-online.com...
> Richard B. Gilbert schrieb:
>
>>
>> Assembler language programming is just about dead.  The only time it's 
>> really necessary is when you are bootstrapping a new hardware platform. 
>> Even device drivers are now written in C.
>
> Not every CPU instruction has an equivalent HL construct.
> Think of byte swapping or "compare & swap" and friends.
>
>

Our C compiler (and BLISS and Pascal) have builtins to let you access such 
atomic sequences.  You don't need asm() and you don't need to write in 
assembler.

On I64, the only place where assembler makes sense is where you are way 
outside the Calling Standard doing argument shuffling.  VMS' exception 
handling comes to mind.

John 

In article <ggk88t$4md$2@aioe.org>, Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Mark Wickens wrote:
> 
>> Could anyone suggest a program with a decent amount of C and MACRO code?
>>  I'm also after suggestions as to what library I should use to write a
>> character-terminal screen based application in C/MACRO.
> 
> My first thought was Kermit, but I believe that is mostly Bliss-32.
> 
> The beginning of VMS was before C, or at least before C was
> well known.
> 
> Kermit is a character/terminal screen based application, though.

   While there is a version of kermit implemented in BLISS, the current
   and maintained version is in C.

In article <GpadncGMsqm9UbDUnZ2dnUVZ_tjinZ2d@earthlink.com>, "John Reagan" <johnrreagan@earthlink.net> writes:
> 
> Not to discourage you, but honestly why learn the instruction set of a 
> computer from the 1970's which isn't even made anymore?
> 

   I've worked with a whole lot of assemblers over the years, and I'm
   glad I learned VAX first.

   The CISC instruction set of the VAX does what programmers want to do:
   artithmetic, string searches, and HLL calls.

   IA-32 is a good example of the other end.  It's CISC insructions do
   what hardware engineers want to do:  move data and jump.

   IMHO a lot of RISC instruction sets are easier to learn than all
   the hacks that went into making an 8 bit 8086 architecture 16 bit and 
   then 32 bit.

   I'm going to teach my kids assembly, using a VAX.  And I'll keep
   running my Macro-32 code on all my VMS machines.

In article <492dcf0f$0$90264$14726298@news.sunsite.dk>, =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
> 
> C has macros.

   ROTFLOL.

In article <ZeqdndDIiNbgTbDUnZ2dnUVZ_o_inZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> There are a few situations where a programmer must work around the 
> typing rules.  They are rare and generally occur when somebody has to 
> convert binary data from platform "A" for use on platform "B".

   Just try passing the address of an array to a $QIO in Ada 86, so you
   can talk to a DRQ3B.

In article <zIGdndSzyOBLebDUnZ2dnUVZ_vninZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> But note that, given the proper software, you can compile VAX Macro to 
> produce Alpha object code.  I wouldn't be surprised if this could also 
> be done on Itanic.

   I would be very surprised if all the Macro-32 came out of VMS by the
   time the port to Itanium was done.  In any case the Macro-32 compiler
   for Itanium ships with VMS.

   Macro was good for making quick access to instructions like MOVC5
   back before there were LIB$x routines for them.  Also for writing
   device drivers on VAXen so that we could hang just about anything
   off our systems.  And, of course, for user written system services
   to provide things VMS 2.x didn't.

   It was also good when I was trying to learn C quickly, because I
   could look at the listing to see what that totaly inconsistent
   syntax had actually meant.

In article <i8qdnSfHr_1m2bPUnZ2dnUVZ_q7inZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> Assembler language programming is just about dead.  The only time it's 
> really necessary is when you are bootstrapping a new hardware platform. 

   Which means people who can do it will be rare and demand higher
   salaries.  While the masses slave on in Visual Basic.

   Ever try to do dump analysis without knowing the instruction set?

   OS and embedded systems programmers do it all the time.

In article <ggm3as$9pr$1@lnx107.hrz.tu-darmstadt.de>, m.kraemer@gsi.de (Michael Kraemer) writes:
> 
> Assembly on 68K is almost like C.

   Hmm.  In my experience it's more like C thinks like a PDP-11.
  

Bob Koehler wrote:
> In article <ZeqdndDIiNbgTbDUnZ2dnUVZ_o_inZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> There are a few situations where a programmer must work around the 
>> typing rules.  They are rare and generally occur when somebody has to 
>> convert binary data from platform "A" for use on platform "B".
> 
>    Just try passing the address of an array to a $QIO in Ada 86, so you
>    can talk to a DRQ3B.
> 

My knowledge of ADA is almost non-existent!  The people I've talked with 
  who do use ADA say that you CAN do almost anything; but you may have 
to provide the compiler with an extensive explanation of what you are 
trying to do.  This is as it should be.  A program that uses the same 
address to store a float and a long int is a disaster waiting to happen.
The original may work just fine but when it's modified. . . .

In article <e54f664d-c557-4de0-bde0-36c8835f012d@v42g2000yqv.googlegroups.com>, johnwallace4@yahoo.co.uk writes:
> 
> It is an allegedly well known fact that much of C was inspired by
> PDP11 assembly, opcodes, and addressing modes, and at first glance it
> seems plausible. However, I'm not sure I believe it as (a) I think
> I've read an interview (with Dennis Ritchie?, who may perhaps be
> considered definitive) which claims there's no truth to it, though I
> can't remember where I read it (b) you can subtract two bytes in C and
> you can't (trivially) subtract bytes on a PDP11, even though most
> other popular PDP11 instructions had byte variants where applicable.

   I think it's ideas like autoincrement and autodecrement that point
   out common thinking between C and PDP-11.  That, and PDP-11 seemed
   to be quite popular at Bell Labs at about the time C was invented.

In article <176uZD2KcidF-pn2-zSoxvSJxPRqB@rikki.tavi.co.uk>, "Bob Eager" <rde42@spamcop.net> writes:
> 
> I programmed PDP-11 stuff for years, and never actually noticed the lack
> of a byte subtract...! Never needed it I guess... I may have been too 
> ashamed to say so earlier...
> 

   Yeah, but did anybody evfer actually find a use for the MARK
   instruction?  The best I could do was to push MARK on the stack
   and then remeber where I'd left it.

   Not in the least bit surprising that MARK was  the only user mode 
   instruction that wasn't needed in compatability mode (RSX-11M/M+ 
   don't use it and thier compilers don't generate it).

In article <ggnoeu$idm$1@aioe.org>, Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> 
> Yes, but C descended from BCPL and B, which were older
> than the PDP-11.

   Did BCPL or B have ++ and -- operators?  Did they assume byte
   addressable memory and a built in stack?

On Nov 28, 1:12=A0pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> Neil Rieck wrote:
> > Correct. Unless you are attending a college course titled "ancient
> > programming tools from the CISC era", C is a much better choice.
> > Sometimes "C" is even a better choice for CISC projects.
>
> CISC seems to be living very well.
>
> I don't think Intel and AMD are that scared by PPC, SPARC and IA-64.
>
> Arne

I don't want to start a flame war but both Intel and AMD call their
popular products RISC machines which happen to be able to run CISC
code. This claim was probably engineered by sales folk because I never
think of the descendants of Pentium4 as pure RISC architectures.

Neil

Neil Rieck wrote:
> On Nov 28, 1:12 pm, Arne Vajh�j <a...@vajhoej.dk> wrote:
>> Neil Rieck wrote:
>>> Correct. Unless you are attending a college course titled "ancient
>>> programming tools from the CISC era", C is a much better choice.
>>> Sometimes "C" is even a better choice for CISC projects.
>> CISC seems to be living very well.
>>
>> I don't think Intel and AMD are that scared by PPC, SPARC and IA-64.
> 
> I don't want to start a flame war but both Intel and AMD call their
> popular products RISC machines which happen to be able to run CISC
> code. This claim was probably engineered by sales folk because I never
> think of the descendants of Pentium4 as pure RISC architectures.

Not even close.

They are CISC.

They were CISC 20 years ago and *adding* more complex
instructions did not make them RISC by magic.

Arne

PS: I don't think I have ever seen Intel/AMD claim that x86 or x86-64
     to be RISC.

On Fri, 28 Nov 2008 22:41:07 UTC, 
koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:

> In article <ggnoeu$idm$1@aioe.org>, Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> > 
> > Yes, but C descended from BCPL and B, which were older
> > than the PDP-11.
> 
>    Did BCPL or B have ++ and -- operators?  Did they assume byte
>    addressable memory and a built in stack?

Not sure if this was rhetorical or not. But anyway...no autoincrement or
autodecrement in BCPL. Memory was word addressable although a byte 
indexing operator (%) eventually appeared. It used a 'stack machine' and
it was actually harder to use the PDP-11 stack than it was to use a 
separate one. I did do a compiler for the VAX later, and managed to use 
FP and SP (but not really AP).

Don't know about B.

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

On Fri, 28 Nov 2008 22:39:02 UTC, 
koehler@eisner.nospam.encompasserve.org (Bob Koehler) wrote:

> In article <176uZD2KcidF-pn2-zSoxvSJxPRqB@rikki.tavi.co.uk>, "Bob Eager" <rde42@spamcop.net> writes:
> > 
> > I programmed PDP-11 stuff for years, and never actually noticed the lack
> > of a byte subtract...! Never needed it I guess... I may have been too 
> > ashamed to say so earlier...
> 
>    Yeah, but did anybody evfer actually find a use for the MARK
>    instruction?  The best I could do was to push MARK on the stack
>    and then remeber where I'd left it.
> 
>    Not in the least bit surprising that MARK was  the only user mode 
>    instruction that wasn't needed in compatability mode (RSX-11M/M+ 
>    don't use it and thier compilers don't generate it).

I tried to use MARK once when I was writing a compiler. I gave up in the
end!

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

yyyc186 wrote:
(snip)

> Anyone who *willingly* chooses an Itanium boat anchor should get
> themselves to a doctor.

Have you priced boat anchors lately?

-- glen

Bob Koehler wrote:
(snip)

>>Kermit is a character/terminal screen based application, though.

>    While there is a version of kermit implemented in BLISS, the current
>    and maintained version is in C.

It might have been around 1985 when I first started using
Kermit with VMS.   Mostly transferring files to/from RT-11 and
then DOS systems.

-- glen

Bob Koehler wrote:
> In article <ggnoeu$idm$1@aioe.org>, Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> Yes, but C descended from BCPL and B, which were older
>> than the PDP-11.
> 
>    Did BCPL or B have ++ and -- operators?  Did they assume byte
>    addressable memory and a built in stack?
> 

I suspect that the ONLY way to find out at this point would be to catch 
Kernighan or Plauger and ask them.  I'm not sure that either language 
ever escaped from the research laboratories!

Neil Rieck wrote:
(snip)

> I don't want to start a flame war but both Intel and AMD call their
> popular products RISC machines which happen to be able to run CISC
> code. This claim was probably engineered by sales folk because I never
> think of the descendants of Pentium4 as pure RISC architectures.

I believe AMD started, and Intel continued, the idea of having
the processor internally convert the CISC instruction stream
to RISCops and pass them through to the RISC part of the processor.

I don't know if any will let you write RISCop code directly, though.

It is much easier to do out-of-order execution at the RISCop level.

-- glen

-- glen

Neil Rieck wrote:
> On Nov 28, 1:12 pm, Arne Vajh�j <a...@vajhoej.dk> wrote:
>> Neil Rieck wrote:
>>> Correct. Unless you are attending a college course titled "ancient
>>> programming tools from the CISC era", C is a much better choice.
>>> Sometimes "C" is even a better choice for CISC projects.
>> CISC seems to be living very well.
>>
>> I don't think Intel and AMD are that scared by PPC, SPARC and IA-64.
>>
>> Arne
> 
> I don't want to start a flame war but both Intel and AMD call their
> popular products RISC machines which happen to be able to run CISC
> code. This claim was probably engineered by sales folk because I never
> think of the descendants of Pentium4 as pure RISC architectures.
> 
> Neil

ISTR reading that the Pentium was actually RISC underneath and had a 
CISC "outer layer".

On Fri, 28 Nov 2008 22:53:14 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:

> > I don't want to start a flame war but both Intel and AMD call their
> > popular products RISC machines which happen to be able to run CISC
> > code. This claim was probably engineered by sales folk because I never
> > think of the descendants of Pentium4 as pure RISC architectures.
>  
> Not even close.
>  
> They are CISC.
>  
> They were CISC 20 years ago and *adding* more complex
> instructions did not make them RISC by magic.
>  
> PS: I don't think I have ever seen Intel/AMD claim that x86 or x86-64
>      to be RISC.

I think the origin of this is simply that internally, that's how they 
work. All the instructions are broken down into RISC equivalents, as 
that makes lots of things (pipe scheduling for one) much easier.

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

On Fri, 28 Nov 2008 23:03:57 UTC, "Richard B. Gilbert" 
<rgilbert88@comcast.net> wrote:

> Bob Koehler wrote:
> > In article <ggnoeu$idm$1@aioe.org>, Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> >> Yes, but C descended from BCPL and B, which were older
> >> than the PDP-11.
> > 
> >    Did BCPL or B have ++ and -- operators?  Did they assume byte
> >    addressable memory and a built in stack?
> > 
> 
> I suspect that the ONLY way to find out at this point would be to catch 
> Kernighan or Plauger and ask them.  I'm not sure that either language 
> ever escaped from the research laboratories!

BCPL did. In quite heavy use here at one point.

I did a substantial compiler for a query language for Dun and Bradstreet
once. Initially on an ICL 2900, where BCPL was the only available and 
suitable language (don't even ask!). But I then very quickly got it 
going very nicely on VMS (the BCPL compiler and then the query language 
compiler written in BCPL).

We also wrote some nice little Z80-based terminal concentrators in BCPL.
I sold a compiler to someone for a massive teleprocessing project 
written in BCPL. Quite a few others, too. A nice little earner.

Remember that BCPL came from the UK....Bell Labs just derived B from it.
-- 
Bob Eager
Use the BIG mirror service in the UK:
http://www.mirrorservice.org

On Fri, 28 Nov 2008 23:05:44 UTC, "Richard B. Gilbert" 
<rgilbert88@comcast.net> wrote:

> Neil Rieck wrote:
> > On Nov 28, 1:12 pm, Arne Vajhj <a...@vajhoej.dk> wrote:
> >> Neil Rieck wrote:
> >>> Correct. Unless you are attending a college course titled "ancient
> >>> programming tools from the CISC era", C is a much better choice.
> >>> Sometimes "C" is even a better choice for CISC projects.
> >> CISC seems to be living very well.
> >>
> >> I don't think Intel and AMD are that scared by PPC, SPARC and IA-64.
> >>
> >> Arne
> > 
> > I don't want to start a flame war but both Intel and AMD call their
> > popular products RISC machines which happen to be able to run CISC
> > code. This claim was probably engineered by sales folk because I never
> > think of the descendants of Pentium4 as pure RISC architectures.
> > 
> > Neil
> 
> ISTR reading that the Pentium was actually RISC underneath and had a 
> CISC "outer layer".

Yup. As previously stated, it makes out-of-order stuff much easier. 
There's quite a bit here:

  http://tinyurl.com/stokes-book
-- 
Bob Eager
Use the BIG mirror service in the UK:
http://www.mirrorservice.org

Bob Eager wrote:
> On Fri, 28 Nov 2008 22:53:14 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
> 
>>> I don't want to start a flame war but both Intel and AMD call their
>>> popular products RISC machines which happen to be able to run CISC
>>> code. This claim was probably engineered by sales folk because I never
>>> think of the descendants of Pentium4 as pure RISC architectures.
>>  
>> Not even close.
>>  
>> They are CISC.
>>  
>> They were CISC 20 years ago and *adding* more complex
>> instructions did not make them RISC by magic.
>>  
>> PS: I don't think I have ever seen Intel/AMD claim that x86 or x86-64
>>      to be RISC.
> 
> I think the origin of this is simply that internally, that's how they 
> work. All the instructions are broken down into RISC equivalents, as 
> that makes lots of things (pipe scheduling for one) much easier.

Maybe.

But I believe that CISC/RISC always has been in the context of the
exposed instruction set.

Arne

Glen Herrmannsfeldt wrote:
> Neil Rieck wrote:
>> I don't want to start a flame war but both Intel and AMD call their
>> popular products RISC machines which happen to be able to run CISC
>> code. This claim was probably engineered by sales folk because I never
>> think of the descendants of Pentium4 as pure RISC architectures.
> 
> I believe AMD started, and Intel continued, the idea of having
> the processor internally convert the CISC instruction stream
> to RISCops and pass them through to the RISC part of the processor.
> 
> I don't know if any will let you write RISCop code directly, though.
> 
> It is much easier to do out-of-order execution at the RISCop level.

Sure.

But that is not the exposed instruction set.

It is more like a specific way of implementing microcode.

Arne

Arne Vajh�j wrote:

> But I believe that CISC/RISC always has been in the context of the
> exposed instruction set.

I would tend to agree. And it is the exposed instruction set which
compilers have to use.

Glen Herrmannsfeldt wrote:
> Bob Koehler wrote:
>>> Kermit is a character/terminal screen based application, though.
>>    While there is a version of kermit implemented in BLISS, the current
>>    and maintained version is in C.
> 
> It might have been around 1985 when I first started using
> Kermit with VMS.   Mostly transferring files to/from RT-11 and
> then DOS systems.

C Kermit is from around 1989-1990. I believe that it
took a few years until C-Kermit was stable enough to replace
the old VMS Kermit.

Arne

Hi Richard,

> There is little reason to write anything in Macro today; device drivers
> can be written in C.  What else was Macro good for?

Many have already pointed out the benefits of macros (not to mention
MACRO-32's string and descriptor support being feature-rich when compared to
C's) but let me say that MACRO is a far superior language for User-Written
System Services. The ability for layered products like RMS, Rdb, and Tier3
to execute securely, with elevated privilege and inner-mode-protected
resources, in the context of the user process is one of the things that
makes VMS great and distinguishes it from the rest of the pack! (Having said
that, most of you probably just give your VAMP servers SYSPRV anyway and
couldn't care less :-( )

MACRO is also good for compile-time initialization of global PSECTs and
external symbol definition.

BTW, I recall some guys at Digital in CHCH circa '92 finding Macro useful as
they could COBOL/MACHINE_CODE and work out how the quadword arithmatic was
being done and then try to copy it in C :-)

Regards Richard Maher

PS. Why is there so many on-topic and interesting posts lately? COV is
taking a lot longer to read.

"Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message
news:zIGdndSzyOBLebDUnZ2dnUVZ_vninZ2d@giganews.com...
> Arne Vajh�j wrote:
> > Mark Wickens wrote:
> >> Jan-Erik S�derholm wrote:
> >>> I can't help to ask, why ?
> >>> Why write an "application" (whatever that is) in MACRO ?
> >
> >> Thanks for the replies - yes asking 'why' is a good question.
> >>
> >> This is purely an academic exercise - I am doing my 'learn one language
> >> a year' and this year it is MACRO-32.
> >
> > If you want to code in assembler, then Macro-32 is probably one
> > of the easiest instruction sets to code in - its CISC'ness
> > makes it much easier that anything else I have tried.
> >
> > But note that VAX'es stopped being produced in the mid 90's.
> >
>
> But note that, given the proper software, you can compile VAX Macro to
> produce Alpha object code.  I wouldn't be surprised if this could also
> be done on Itanic.
>
> ISTR doing this once nine or ten years ago.  I had some useful snippet
> written in macro and wanted to use it on Alpha. . . .
>
> There is little reason to write anything in Macro today; device drivers
> can be written in C.  What else was Macro good for?
>
> The days when the ability to hand optimize code was useful are long gone
> along with the machines on which hand optimization could make a
> significant difference!

Arne Vajh�j wrote:

> C Kermit is from around 1989-1990. I believe that it
> took a few years until C-Kermit was stable enough to replace
> the old VMS Kermit.

Unix C kermit is older than that.  For other than unix,
that might be about right.

-- glen

On Fri, 28 Nov 2008 10:08:47 -0800, Arne Vajh�j <arne@vajhoej.dk> wrote:

> Tom Linden wrote:
>> On Fri, 28 Nov 2008 08:16:25 -0800, Arne Vajh�j <arne@vajhoej.dk> wrote:
>>> Tom Wade wrote:
>>>>> "Good example in C" I would suggest is an oxymoron.
>>>>  C is a language that combines the power and flexibility of assembler  
>>>> with the readability and ease of use of assembler.
>>>
>>> Even if it is a joke, then it has some foundation in reality. It
>>> is not possible to create a language that gives you full flexibility
>>> to do the tricks you want and still prevent you from doing mistakes.
>>> Either you have the cake or you eat it.
>>  Some cakes are tastier than others.
>
> We all know that you prefer [BCDFGHJKLMNPQRSTWVXZ]{2}/[AEIOUY]{1}
> cakes.
>
> :-)
>
> Arne

cute

-- 
PL/I for OpenVMS
www.kednos.com

On Fri, 28 Nov 2008 15:20:21 -0800, Arne Vajh�j <arne@vajhoej.dk> wrote:

> Bob Eager wrote:
>> On Fri, 28 Nov 2008 22:53:14 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
>>
>>>> I don't want to start a flame war but both Intel and AMD call their
>>>> popular products RISC machines which happen to be able to run CISC
>>>> code. This claim was probably engineered by sales folk because I never
>>>> think of the descendants of Pentium4 as pure RISC architectures.
>>>  Not even close.
>>>  They are CISC.
>>>  They were CISC 20 years ago and *adding* more complex
>>> instructions did not make them RISC by magic.
>>>  PS: I don't think I have ever seen Intel/AMD claim that x86 or x86-64
>>>      to be RISC.
>>  I think the origin of this is simply that internally, that's how they  
>> work. All the instructions are broken down into RISC equivalents, as  
>> that makes lots of things (pipe scheduling for one) much easier.
>
> Maybe.
>
> But I believe that CISC/RISC always has been in the context of the
> exposed instruction set.
>
> Arne
Bob is correct.  They started building RISC cores at some point with the
386.  I had a few discussions with John Crawford at that time,  must have
been late 80's.  Basically they are emulation engines.  If you think about
it this is not a lot different than was done in the early 70's with the
2901 bit slice machines, but they were a lot harder to program and build
instructions sets with.  Prime actully did both V-mode (accumulator  
architecture)
and I-mode (general register) with the same hardware by reprogramming the
microcode.




-- 
PL/I for OpenVMS
www.kednos.com

On Fri, 28 Nov 2008 19:22:55 -0800, Glen Herrmannsfeldt  
<gah@ugcs.caltech.edu> wrote:

> Arne Vajh�j wrote:
>
>> C Kermit is from around 1989-1990. I believe that it
>> took a few years until C-Kermit was stable enough to replace
>> the old VMS Kermit.
>
> Unix C kermit is older than that.  For other than unix,
> that might be about right.

I used it around 1981

>
> -- glen
>



-- 
PL/I for OpenVMS
www.kednos.com

On Nov 29, 5:06=A0am, "Tom Linden" <t...@kednos.company> wrote:
> On Fri, 28 Nov 2008 15:20:21 -0800, Arne Vajh=F8j <a...@vajhoej.dk> wrote=
:
> > Bob Eager wrote:
> >> On Fri, 28 Nov 2008 22:53:14 UTC, Arne Vajh j <a...@vajhoej.dk> wrote:
>
> >>>> I don't want to start a flame war but both Intel and AMD call their
> >>>> popular products RISC machines which happen to be able to run CISC
> >>>> code. This claim was probably engineered by sales folk because I nev=
er
> >>>> think of the descendants of Pentium4 as pure RISC architectures.
> >>> =A0Not even close.
> >>> =A0They are CISC.
> >>> =A0They were CISC 20 years ago and *adding* more complex
> >>> instructions did not make them RISC by magic.
> >>> =A0PS: I don't think I have ever seen Intel/AMD claim that x86 or x86=
-64
> >>> =A0 =A0 =A0to be RISC.
> >> =A0I think the origin of this is simply that internally, that's how th=
ey =A0
> >> work. All the instructions are broken down into RISC equivalents, as =
=A0
> >> that makes lots of things (pipe scheduling for one) much easier.
>
> > Maybe.
>
> > But I believe that CISC/RISC always has been in the context of the
> > exposed instruction set.
>
> > Arne
>
> Bob is correct. =A0They started building RISC cores at some point with th=
e
> 386. =A0I had a few discussions with John Crawford at that time, =A0must =
have
> been late 80's. =A0Basically they are emulation engines. =A0If you think =
about
> it this is not a lot different than was done in the early 70's with the
> 2901 bit slice machines, but they were a lot harder to program and build
> instructions sets with. =A0Prime actully did both V-mode (accumulator =A0
> architecture)
> and I-mode (general register) with the same hardware by reprogramming the
> microcode.
>
> --
> PL/I for OpenVMSwww.kednos.com

Bitslice wasn't just for division 2 players like Prime. The VAX 730
was a 2900 (29000?)-series bitslice machine, wasn't it? What else
could folk have done with a 730 if they'd known what magick to put on
the TU58s? Probably not much of any great usefulness, as the whole
point was to run VMS - if you didn't need VMS, there were x86s, and
68ks and other trendy young cheap'n'cheerful things coming up fast
(but without VMS).

On 2008-11-29, johnwallace4@yahoo.co.uk <johnwallace4@yahoo.co.uk> wrote:
> On Nov 29, 5:06�am, "Tom Linden" <t...@kednos.company> wrote:
>> If you think about
>> it this is not a lot different than was done in the early 70's with the
>> 2901 bit slice machines, but they were a lot harder to program and build
>> instructions sets with.
>
> Bitslice wasn't just for division 2 players like Prime. The VAX 730
> was a 2900 (29000?)-series bitslice machine, wasn't it? What else
> could folk have done with a 730 if they'd known what magick to put on
> the TU58s?

To veer back slightly towards topic, one of the things that I do with
MACRO32 is assemble microcode for a 2910/29116 controller. The microcode
was originally written using META29R, which we only have on a VAX. Since
I moved the microcode to MACRO32, I can now assemble microcode on VAXen,
Alphas, and Itania.

MACRO32 is very powerful and I like it a lot.
-- 
roger ivie
rivie@ridgenet.net

Roger Ivie wrote:
(snip)

> To veer back slightly towards topic, one of the things that I do with
> MACRO32 is assemble microcode for a 2910/29116 controller. The microcode
> was originally written using META29R, which we only have on a VAX. Since
> I moved the microcode to MACRO32, I can now assemble microcode on VAXen,
> Alphas, and Itania.

Is Itania the oxide of Itanium?

Actually, I don't like the convention, but it is popular
with chemists.

-- glen

On Fri, 28 Nov 2008 23:20:21 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:

> Bob Eager wrote:
> > On Fri, 28 Nov 2008 22:53:14 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
> > 
> >>> I don't want to start a flame war but both Intel and AMD call their
> >>> popular products RISC machines which happen to be able to run CISC
> >>> code. This claim was probably engineered by sales folk because I never
> >>> think of the descendants of Pentium4 as pure RISC architectures.
> >>  
> >> Not even close.
> >>  
> >> They are CISC.
> >>  
> >> They were CISC 20 years ago and *adding* more complex
> >> instructions did not make them RISC by magic.
> >>  
> >> PS: I don't think I have ever seen Intel/AMD claim that x86 or x86-64
> >>      to be RISC.
> > 
> > I think the origin of this is simply that internally, that's how they 
> > work. All the instructions are broken down into RISC equivalents, as 
> > that makes lots of things (pipe scheduling for one) much easier.
> 
> Maybe.
> 
> But I believe that CISC/RISC always has been in the context of the
> exposed instruction set.

I would agree..! I'm just reporting what I believe to be the origin of 
the idea. Plus of course, marketing...as always.

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

"Richard Maher" <maher_rj@hotspamnotmail.com> writes:

>> There is little reason to write anything in Macro today; device drivers
>> can be written in C.  What else was Macro good for?

>Many have already pointed out the benefits of macros (not to mention
>MACRO-32's string and descriptor support being feature-rich when compared to
>C's)

Another interesting use of Macro-32 and macros I've seen is to "compile"
data files into binary tables, for use in an application where the tables
change occasionally.  For each table, there's one set of macros that
define the data structure (kind of like a C .H file with struct definitions)
and a second set of macros that process the table commands themselves, the
"source" consists of macro calls that fill the tables, one macro call per
table row.  The second set of macros contains largely of
..BYTE/.WORD/.LONG/.ASCII references, the object of which may be pointers
to table entries in other tables.

These tables are linked against each other, resolved by the macro 
assembler/compiler.

You don't want to know how to get from the "executable" images to data
files, esp. how to get the process working on the Itanium.

As kludgy as this process is, I don't know of a better way.

In article <iPSdnQmedoe2763UnZ2dnUVZ_hmdnZ2d@giganews.com>,
	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> Bob Koehler wrote:
>> In article <ZeqdndDIiNbgTbDUnZ2dnUVZ_o_inZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>>> There are a few situations where a programmer must work around the 
>>> typing rules.  They are rare and generally occur when somebody has to 
>>> convert binary data from platform "A" for use on platform "B".
>> 
>>    Just try passing the address of an array to a $QIO in Ada 86, so you
>>    can talk to a DRQ3B.
>> 
> 
> My knowledge of ADA is almost non-existent!  The people I've talked with 
>   who do use ADA say that you CAN do almost anything; but you may have 
> to provide the compiler with an extensive explanation of what you are 
> trying to do.  

Ah yes, Ada.  I remember hearing about all the bad things that C does
that Ada doesn't, which is what made Ada so superior.  Until you look
at the last chapter of the Ada textbook they used here that basicly
showed how to get around all that string typecasting stiff.  :-)  And
all kinds of other dirty little tricks that someone decided really were
necesary writing programs in the real world.

>                This is as it should be.  A program that uses the same 
> address to store a float and a long int is a disaster waiting to happen.
> The original may work just fine but when it's modified. . . .

OK.  But what about storing 6 ASCII characters packed into one REAL*4
variable?  :-)

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

In article <ggqcj2$ken$1@aioe.org>,
	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Arne Vajh�j wrote:
> 
>> C Kermit is from around 1989-1990. I believe that it
>> took a few years until C-Kermit was stable enough to replace
>> the old VMS Kermit.
> 
> Unix C kermit is older than that.  For other than unix,
> that might be about right.
> 

The BLISS version worked just fine as far as I was concerned.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

Bill Gunshannon wrote:
> In article <ggqcj2$ken$1@aioe.org>,
> 	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> Arne Vajh�j wrote:
>>
>>> C Kermit is from around 1989-1990. I believe that it
>>> took a few years until C-Kermit was stable enough to replace
>>> the old VMS Kermit.
>> Unix C kermit is older than that.  For other than unix,
>> that might be about right.
>>
> 
> The BLISS version worked just fine as far as I was concerned.

The Bliss version was rock solid.

But if I remember correctly, then the C version had
better performance (due to ability to use larger
buffers or something like that).

Arne

Richard B. Gilbert skrev:
> Bob Koehler wrote:
>> In article <ggnoeu$idm$1@aioe.org>, Glen Herrmannsfeldt 
>> <gah@ugcs.caltech.edu> writes:
>>> Yes, but C descended from BCPL and B, which were older
>>> than the PDP-11.
>>
>>    Did BCPL or B have ++ and -- operators?  Did they assume byte
>>    addressable memory and a built in stack?
>>
> 
> I suspect that the ONLY way to find out at this point would be to catch 
> Kernighan or Plauger and ask them.  I'm not sure that either language 
> ever escaped from the research laboratories!

I havae BCPL for RSX here. It actually comes from DECUS.
I also think that parts of the system in the AMIGA was written in BCPL.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

On Sat, 29 Nov 2008 01:09:08 -0800, Glen Herrmannsfeldt  
<gah@ugcs.caltech.edu> wrote:

> Roger Ivie wrote:
> (snip)
>
>> To veer back slightly towards topic, one of the things that I do with
>> MACRO32 is assemble microcode for a 2910/29116 controller. The microcode
>> was originally written using META29R, which we only have on a VAX. Since
>> I moved the microcode to MACRO32, I can now assemble microcode on VAXen,
>> Alphas, and Itania.
>
> Is Itania the oxide of Itanium?

Yes, it is a sun block

>
> Actually, I don't like the convention, but it is popular
> with chemists.
>
> -- glen
>



-- 
PL/I for OpenVMS
www.kednos.com

Bob Koehler skrev:
> In article <176uZD2KcidF-pn2-zSoxvSJxPRqB@rikki.tavi.co.uk>, "Bob Eager" <rde42@spamcop.net> writes:
>> I programmed PDP-11 stuff for years, and never actually noticed the lack
>> of a byte subtract...! Never needed it I guess... I may have been too 
>> ashamed to say so earlier...
>>
> 
>    Yeah, but did anybody evfer actually find a use for the MARK
>    instruction?  The best I could do was to push MARK on the stack
>    and then remeber where I'd left it.

Yes, that's the way it is intended to be used.

>    Not in the least bit surprising that MARK was  the only user mode 
>    instruction that wasn't needed in compatability mode (RSX-11M/M+ 
>    don't use it and thier compilers don't generate it).

MARK is actually a very shitty instruction, which don't even work if you have 
split I/D space. It was a nice idea, but it just didn't turn out that nice in 
reality. And VAX then went in another, saner direction for stack handling, call 
frames and argument pointers.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

On Sat, 29 Nov 2008 05:34:50 -0800, Michael Moroney  
<moroney@world.std.spaamtrap.com> wrote:

> "Richard Maher" <maher_rj@hotspamnotmail.com> writes:
>
>>> There is little reason to write anything in Macro today; device drivers
>>> can be written in C.  What else was Macro good for?
>
>> Many have already pointed out the benefits of macros (not to mention
>> MACRO-32's string and descriptor support being feature-rich when  
>> compared to
>> C's)
>
> Another interesting use of Macro-32 and macros I've seen is to "compile"
> data files into binary tables, for use in an application where the tables
> change occasionally.  For each table, there's one set of macros that
> define the data structure (kind of like a C .H file with struct  
> definitions)
> and a second set of macros that process the table commands themselves,  
> the
> "source" consists of macro calls that fill the tables, one macro call per
> table row.  The second set of macros contains largely of
> .BYTE/.WORD/.LONG/.ASCII references, the object of which may be pointers
> to table entries in other tables.
>
> These tables are linked against each other, resolved by the macro
> assembler/compiler.
>
> You don't want to know how to get from the "executable" images to data
> files, esp. how to get the process working on the Itanium.
>
> As kludgy as this process is, I don't know of a better way.

Maybe I missed something, but that sounds like a commonplace activity for
PL/I. You don't need executable code to define dynamic data structures.
The second set is standard I/O.

>



-- 
PL/I for OpenVMS
www.kednos.com

johnwallace4@yahoo.co.uk skrev:
> On Nov 28, 12:54 am, Roger Ivie <ri...@ridgenet.net> wrote:
>> On 2008-11-27, johnwalla...@yahoo.co.uk <johnwalla...@yahoo.co.uk> wrote:
>>
>>> Now if you'd said the National
>>> Semiconductor NS16000 had been inspired by VAX with the additional
>>> design goals of modernisation, removal of cruft, and simple support
>>> for ROMable code, I'd have agreed with that.
>> Pfft. I've never understood how people can say that when the NS16000
>> doesn't even have the PC as a general-purpose register.
>> --
>> roger ivie
>> ri...@ridgenet.net
> 
> NS16000 wasn't a VAX clone (the Russians did those, right?), it wasn't
> even trying to be VAX compatible, but chunks of it might well have
> been VAX-inspired. Anyway, if you can still achieve all the relevant
> addressing modes using PC-relative addressing, module pointers, etc,
> which iirc the NS16000 could, what do you actually lose by not having
> the PC as a general register? (or is it my turn for a sense of humour
> failure?) Obviously you can't do the usual party tricks like MOV -
> (R7), -(R7) like some PDP11s could, but so what? Anyway, history has
> shown that a nice instruction set architecture is not necessarily
> guarantee of, or even a prerequisite for, market success. Not then,
> not now.

The big point of having the PC as a general register is that you don't need 
special opcodes for the instructions when you want to address things 
PC-relative. It's just a normal addressing mode, with a general register.
It makes a lot of things easier. But sure, you can accomplish the same thing 
without that feature. But it makes life more difficult.

Let me give you an example:
The 68K are pretty inspired by the PDP11 and VAX. But they don't have the PC as 
a general register. Instead you have specific opcodes for variations of the 
instruction. Take CMP (compare) - in the 68K you have compare, and you have 
compare immediate.
In an assembler, you'd write

	CMP.B	#'A,D0

for instance. And the assembler would know that that's actually a special 
version of CMP.B, which takes one immediate argument, and one (data) register.
If you instead wrote

	CMP.B	D0,D1

it would assemble to another opcode.

And you might say "so what". That's all the responsobility of the assembler, and 
I as a programmer don't have to worry or think about it. And it causes the same 
end result as if you would have programmed on a PDP11 or a VAX.

All very true. But consider this. On a PDP11 or a VAX, you could also have 
written this:

	CMPB	R0,#'A

and you just can't do that on a 68K. The immediate mode argument can only be the 
first argument, since it's actually a different opcode, and not a generic 
argument to the CMPB instruction (or CMP.B as it would be called on a 68K).

And no, it's not the same. While one can be replaced by the other, they will 
cause different results in the condition codes, and code following it will have 
to be adjusted accordingly. And if you write in assembler, you would probably 
prefer the code to reflect your through instead of having to be adjusted to fit 
into what can be expressed by the instruction set.

There are a whole bunch of variations that can't be expressed because the 68K 
have several different opcodes for CMP which caters to various special 
situations. It's all a *mess*!

> I think Ritchie's in-depth history of C (http://cm.bell-labs.com/cm/cs/
> who/dmr/chist.html) says the auto-increment/auto-decrement stuff came
> from PDP7.

I doubt it. The PDP7 don't stuff like that, and besides, C wasn't designed until 
they had moved to the PDP-11. The first few versions of Unix on the PDP-11 was 
still written in assembler before they moved to C.

But Ritche have also been very clear that the autoincrement and autodecrement 
elements in C were *not* inspired by the PDP-11.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Tom Linden wrote:
> On Sat, 29 Nov 2008 01:09:08 -0800, Glen Herrmannsfeldt 
> <gah@ugcs.caltech.edu> wrote:
> 
>> Roger Ivie wrote:
>> (snip)
>>
>>> To veer back slightly towards topic, one of the things that I do with
>>> MACRO32 is assemble microcode for a 2910/29116 controller. The microcode
>>> was originally written using META29R, which we only have on a VAX. Since
>>> I moved the microcode to MACRO32, I can now assemble microcode on VAXen,
>>> Alphas, and Itania.
>>
>> Is Itania the oxide of Itanium?
> 
> Yes, it is a sun block
> 

Off with his head!!!!!

Johnny Billquist schrieb:

> I also think that parts of the system in the AMIGA was written in BCPL.

Yes, AmigaDOS, i.e. the part which deals with the file system.
Not a good idea in hindsight, because the rest of the system
is coded in C and assembly. BCPL API expects pointers to 4-byte
entities, whereas "normal" pointers are supposed to be byte address.
Confusing these two is a major pitfall and most Amigans view
BCPL-based AmigaDOS as the odd man out of the system.

On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:

> Bill Gunshannon wrote:
> > In article <ggqcj2$ken$1@aioe.org>,
> > 	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> >> Arne Vajhj wrote:
> >>
> >>> C Kermit is from around 1989-1990. I believe that it
> >>> took a few years until C-Kermit was stable enough to replace
> >>> the old VMS Kermit.
> >> Unix C kermit is older than that.  For other than unix,
> >> that might be about right.
> >>
> > 
> > The BLISS version worked just fine as far as I was concerned.
> 
> The Bliss version was rock solid.
> 
> But if I remember correctly, then the C version had
> better performance (due to ability to use larger
> buffers or something like that).

And sliding windows....allowing overlap between send and acknowledge.

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

Anyone wonder if the VMS group ported MACRO32 to Windows or Linux ?
(8086 architecture).

It would be interesting to see a cross platform assembler survive VMS.

On Sat, 29 Nov 2008 15:00:38 UTC, Johnny Billquist <bqt@update.uu.se> 
wrote:

> I also think that parts of the system in the AMIGA was written in BCPL.

Yup...it was based on the TRIPOS operating system, written by some 
undergraduates at the University of Cambridge (UK). I have a copy of 
TRIPOS somewhere...the source code, anyway. I ran it on a PDP-11 for a 
while, after patching the kernel image so it would work on an 11/34!

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

On Sat, 29 Nov 2008 15:00:38 UTC, Johnny Billquist <bqt@update.uu.se> 
wrote:

> I havae BCPL for RSX here. It actually comes from DECUS.
> I also think that parts of the system in the AMIGA was written in BCPL.

I may not have made it clear, but I have BCPL for VMS! Not from 
DECUS....I wrote it.

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

In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>,
	"Bob Eager" <rde42@spamcop.net> writes:
> On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
> 
>> Bill Gunshannon wrote:
>> > In article <ggqcj2$ken$1@aioe.org>,
>> > 	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> >> Arne Vajhj wrote:
>> >>
>> >>> C Kermit is from around 1989-1990. I believe that it
>> >>> took a few years until C-Kermit was stable enough to replace
>> >>> the old VMS Kermit.
>> >> Unix C kermit is older than that.  For other than unix,
>> >> that might be about right.
>> >>
>> > 
>> > The BLISS version worked just fine as far as I was concerned.
>> 
>> The Bliss version was rock solid.
>> 
>> But if I remember correctly, then the C version had
>> better performance (due to ability to use larger
>> buffers or something like that).
> 
> And sliding windows....allowing overlap between send and acknowledge.

Too bad there was no one to just add those features to the Bliss
version.  Hmmmm...  Might be fun to try.  Especially for someone
like me who's only experience with Bliss is knowing it's reputation.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

In article <176uZD2KcidF-pn2-vojyydTuUdQK@rikki.tavi.co.uk>,
	"Bob Eager" <rde42@spamcop.net> writes:
> On Sat, 29 Nov 2008 15:00:38 UTC, Johnny Billquist <bqt@update.uu.se> 
> wrote:
> 
>> I also think that parts of the system in the AMIGA was written in BCPL.
> 
> Yup...it was based on the TRIPOS operating system, written by some 
> undergraduates at the University of Cambridge (UK). I have a copy of 
> TRIPOS somewhere...the source code, anyway. I ran it on a PDP-11 for a 
> while, after patching the kernel image so it would work on an 11/34!

Any chance of getting the PDP-11 stuff?  Some of us still enjoy playing
with ours and I never heard anyone mention this OS.

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

Bill Gunshannon wrote:
> In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>,
> 	"Bob Eager" <rde42@spamcop.net> writes:
>> On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
>>
>>> Bill Gunshannon wrote:
>>>> In article <ggqcj2$ken$1@aioe.org>,
>>>> 	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>>> Arne Vajhj wrote:
>>>>>
>>>>>> C Kermit is from around 1989-1990. I believe that it
>>>>>> took a few years until C-Kermit was stable enough to replace
>>>>>> the old VMS Kermit.
>>>>> Unix C kermit is older than that.  For other than unix,
>>>>> that might be about right.
>>>>>
>>>> The BLISS version worked just fine as far as I was concerned.
>>> The Bliss version was rock solid.
>>>
>>> But if I remember correctly, then the C version had
>>> better performance (due to ability to use larger
>>> buffers or something like that).
>> And sliding windows....allowing overlap between send and acknowledge.
> 
> Too bad there was no one to just add those features to the Bliss
> version.  Hmmmm...  Might be fun to try.  Especially for someone
> like me who's only experience with Bliss is knowing it's reputation.

FDC probably wanted to standardize on C Kermit on all/many platforms
(with a few OS specific modules) to lower the burden of
maintenance.

Arne

JF Mezei wrote:
> Anyone wonder if the VMS group ported MACRO32 to Windows or Linux ?
> (8086 architecture).
> 
> It would be interesting to see a cross platform assembler survive VMS.

Considering that the main purpose of Macro-32 is to build code
originally developed on VMS VAX, then I don't see much need
on Windows and Linux - even if the code compiled, then
it would not link and run due to dependencies on RTL,
descriptors etc..

Arne

JF Mezei wrote:
> Anyone wonder if the VMS group ported MACRO32 to Windows or Linux ?
> (8086 architecture).
> 
> It would be interesting to see a cross platform assembler survive VMS.

Why would anyone port Macro32 to Windows?  There are X86 assemblers 
available; I used a couple, many years ago.

As for Linux, which platform did you have in mind?  And why Macro32? 
Don't the various Linux versions support their own assemblers?

If there is a market, you could be the first to enter it!

Richard B. Gilbert wrote:
> As for Linux, which platform did you have in mind?

I guess all of them use the same tool chain. GCC.

> Don't the various Linux versions support their own assemblers?

Yep.

If you save the file as .s then gcc should assemble it.

Arne

Arne Vajh�j wrote:
> Richard B. Gilbert wrote:
>> As for Linux, which platform did you have in mind?
> 
> I guess all of them use the same tool chain. GCC.
> 
>> Don't the various Linux versions support their own assemblers?
> 
> Yep.
> 
> If you save the file as .s then gcc should assemble it.
> 
> Arne

Errr.....  I thought we were talking about Macro-32 here.  Has someone 
ported Linux to the VAX?  Why would anyone want to run Linux on a VAX 
when they could run VMS?????

Richard B. Gilbert wrote:
> Arne Vajh�j wrote:
>> Richard B. Gilbert wrote:
>>> As for Linux, which platform did you have in mind?
>>
>> I guess all of them use the same tool chain. GCC.
>>
>>> Don't the various Linux versions support their own assemblers?
>>
>> Yep.
>>
>> If you save the file as .s then gcc should assemble it.
> 
> Errr.....  I thought we were talking about Macro-32 here.  Has someone 
> ported Linux to the VAX?  Why would anyone want to run Linux on a VAX 
> when they could run VMS?????

We were talking about whether Linux had its own assembler
(with the impact of porting Macro-32 to Linux not making
any sense).

Arne

Arne Vajh�j wrote:
> Richard B. Gilbert wrote:
>> Arne Vajh�j wrote:
>>> Richard B. Gilbert wrote:
>>>> As for Linux, which platform did you have in mind?
>>>
>>> I guess all of them use the same tool chain. GCC.
>>>
>>>> Don't the various Linux versions support their own assemblers?
>>>
>>> Yep.
>>>
>>> If you save the file as .s then gcc should assemble it.
>>
>> Errr.....  I thought we were talking about Macro-32 here.  Has someone 
>> ported Linux to the VAX?  Why would anyone want to run Linux on a VAX 
>> when they could run VMS?????
> 
> We were talking about whether Linux had its own assembler
> (with the impact of porting Macro-32 to Linux not making
> any sense).
> 
> Arne
> 

The whole thread seems sort of senseless.  It's not VMS related. . . .

In article <493175dd$0$90262$14726298@news.sunsite.dk>,
	Arne Vajh�j <arne@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>,
>> 	"Bob Eager" <rde42@spamcop.net> writes:
>>> On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
>>>
>>>> Bill Gunshannon wrote:
>>>>> In article <ggqcj2$ken$1@aioe.org>,
>>>>> 	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>>>> Arne Vajhj wrote:
>>>>>>
>>>>>>> C Kermit is from around 1989-1990. I believe that it
>>>>>>> took a few years until C-Kermit was stable enough to replace
>>>>>>> the old VMS Kermit.
>>>>>> Unix C kermit is older than that.  For other than unix,
>>>>>> that might be about right.
>>>>>>
>>>>> The BLISS version worked just fine as far as I was concerned.
>>>> The Bliss version was rock solid.
>>>>
>>>> But if I remember correctly, then the C version had
>>>> better performance (due to ability to use larger
>>>> buffers or something like that).
>>> And sliding windows....allowing overlap between send and acknowledge.
>> 
>> Too bad there was no one to just add those features to the Bliss
>> version.  Hmmmm...  Might be fun to try.  Especially for someone
>> like me who's only experience with Bliss is knowing it's reputation.
> 
> FDC probably wanted to standardize on C Kermit on all/many platforms
> (with a few OS specific modules) to lower the burden of
> maintenance.

Having provided platforms for compiling and maintenance of some Kermit
versions as well as having maintained a few myself, I kknow Frank well
enough that I would bet he would put up a newer version if someone went
to the trouble of making one.  I have turned in binaries for versions
of Kermit for machines not able to run C-Kermit, like the PDP-11.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

On Sat, 29 Nov 2008 16:42:31 UTC, billg999@cs.uofs.edu (Bill Gunshannon)
wrote:

> In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>,
> 	"Bob Eager" <rde42@spamcop.net> writes:
> > On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
> > 
> >> Bill Gunshannon wrote:
> >> > In article <ggqcj2$ken$1@aioe.org>,
> >> > 	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> >> >> Arne Vajhj wrote:
> >> >>
> >> >>> C Kermit is from around 1989-1990. I believe that it
> >> >>> took a few years until C-Kermit was stable enough to replace
> >> >>> the old VMS Kermit.
> >> >> Unix C kermit is older than that.  For other than unix,
> >> >> that might be about right.
> >> >>
> >> > 
> >> > The BLISS version worked just fine as far as I was concerned.
> >> 
> >> The Bliss version was rock solid.
> >> 
> >> But if I remember correctly, then the C version had
> >> better performance (due to ability to use larger
> >> buffers or something like that).
> > 
> > And sliding windows....allowing overlap between send and acknowledge.
> 
> Too bad there was no one to just add those features to the Bliss
> version.  Hmmmm...  Might be fun to try.  Especially for someone
> like me who's only experience with Bliss is knowing it's reputation.

The definitions are all in the Kermit protocol book. Probably still 
available used.

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

On Sat, 29 Nov 2008 16:44:44 UTC, billg999@cs.uofs.edu (Bill Gunshannon)
wrote:

> In article <176uZD2KcidF-pn2-vojyydTuUdQK@rikki.tavi.co.uk>,
> 	"Bob Eager" <rde42@spamcop.net> writes:
> > On Sat, 29 Nov 2008 15:00:38 UTC, Johnny Billquist <bqt@update.uu.se> 
> > wrote:
> > 
> >> I also think that parts of the system in the AMIGA was written in BCPL.
> > 
> > Yup...it was based on the TRIPOS operating system, written by some 
> > undergraduates at the University of Cambridge (UK). I have a copy of 
> > TRIPOS somewhere...the source code, anyway. I ran it on a PDP-11 for a 
> > while, after patching the kernel image so it would work on an 11/34!
> 
> Any chance of getting the PDP-11 stuff?  Some of us still enjoy playing
> with ours and I never heard anyone mention this OS.

OK...

   www.tavi.co.uk/TRIPOS.ZIP

Note the upper case filename!
-- 
Bob Eager
Use the BIG mirror service in the UK:
http://www.mirrorservice.org

In article <TsCdnSQAcecj4KzUnZ2dnUVZ_oPinZ2d@giganews.com>,
	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> Arne Vajh�j wrote:
>> Richard B. Gilbert wrote:
>>> As for Linux, which platform did you have in mind?
>> 
>> I guess all of them use the same tool chain. GCC.
>> 
>>> Don't the various Linux versions support their own assemblers?
>> 
>> Yep.
>> 
>> If you save the file as .s then gcc should assemble it.
>> 
>> Arne
> 
> Errr.....  I thought we were talking about Macro-32 here.  Has someone 
> ported Linux to the VAX?  

While it doesn't appear to have seen much (any?) activity in almost three
years, the answer is yes.

>                           Why would anyone want to run Linux on a VAX 
> when they could run VMS?????

Rhetorical question, right?  Running VMS means working with a whole
different animal.  A more reasonable question would be, "Why would
anyone want to run Linux on a VAX when it's just a poor stepchild
to Unix and there are several excelent versions of Unix availble?" :-)

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

In article <493182c2$0$90271$14726298@news.sunsite.dk>,
	Arne Vajh�j <arne@vajhoej.dk> writes:
> Richard B. Gilbert wrote:
>> Arne Vajh�j wrote:
>>> Richard B. Gilbert wrote:
>>>> As for Linux, which platform did you have in mind?
>>>
>>> I guess all of them use the same tool chain. GCC.
>>>
>>>> Don't the various Linux versions support their own assemblers?
>>>
>>> Yep.
>>>
>>> If you save the file as .s then gcc should assemble it.
>> 
>> Errr.....  I thought we were talking about Macro-32 here.  Has someone 
>> ported Linux to the VAX?  Why would anyone want to run Linux on a VAX 
>> when they could run VMS?????
> 
> We were talking about whether Linux had its own assembler
> (with the impact of porting Macro-32 to Linux not making
> any sense).

"Having an assembler" is not even close to "having Macro-32" which
is considerably more than just an assembler for the VAX architecture.
Unless you consider GCC to be just a real high-level Macro Assembler. :-)

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

In article <176uZD2KcidF-pn2-Ygioq8GMIEPI@rikki.tavi.co.uk>,
	"Bob Eager" <rde42@spamcop.net> writes:
> On Sat, 29 Nov 2008 16:42:31 UTC, billg999@cs.uofs.edu (Bill Gunshannon)
> wrote:
> 
>> In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>,
>> 	"Bob Eager" <rde42@spamcop.net> writes:
>> > On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
>> > 
>> >> Bill Gunshannon wrote:
>> >> > In article <ggqcj2$ken$1@aioe.org>,
>> >> > 	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> >> >> Arne Vajhj wrote:
>> >> >>
>> >> >>> C Kermit is from around 1989-1990. I believe that it
>> >> >>> took a few years until C-Kermit was stable enough to replace
>> >> >>> the old VMS Kermit.
>> >> >> Unix C kermit is older than that.  For other than unix,
>> >> >> that might be about right.
>> >> >>
>> >> > 
>> >> > The BLISS version worked just fine as far as I was concerned.
>> >> 
>> >> The Bliss version was rock solid.
>> >> 
>> >> But if I remember correctly, then the C version had
>> >> better performance (due to ability to use larger
>> >> buffers or something like that).
>> > 
>> > And sliding windows....allowing overlap between send and acknowledge.
>> 
>> Too bad there was no one to just add those features to the Bliss
>> version.  Hmmmm...  Might be fun to try.  Especially for someone
>> like me who's only experience with Bliss is knowing it's reputation.
> 
> The definitions are all in the Kermit protocol book. Probably still 
> available used.

I don't think knowledge of Kermit is the problem.  Experience with Bliss
is another matter entirely.  :-)

bill
 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

In article <176uZD2KcidF-pn2-hYI3HRceTyXx@rikki.tavi.co.uk>,
	"Bob Eager" <rde42@spamcop.net> writes:
> On Sat, 29 Nov 2008 16:44:44 UTC, billg999@cs.uofs.edu (Bill Gunshannon)
> wrote:
> 
>> In article <176uZD2KcidF-pn2-vojyydTuUdQK@rikki.tavi.co.uk>,
>> 	"Bob Eager" <rde42@spamcop.net> writes:
>> > On Sat, 29 Nov 2008 15:00:38 UTC, Johnny Billquist <bqt@update.uu.se> 
>> > wrote:
>> > 
>> >> I also think that parts of the system in the AMIGA was written in BCPL.
>> > 
>> > Yup...it was based on the TRIPOS operating system, written by some 
>> > undergraduates at the University of Cambridge (UK). I have a copy of 
>> > TRIPOS somewhere...the source code, anyway. I ran it on a PDP-11 for a 
>> > while, after patching the kernel image so it would work on an 11/34!
>> 
>> Any chance of getting the PDP-11 stuff?  Some of us still enjoy playing
>> with ours and I never heard anyone mention this OS.
> 
> OK...
> 
>    www.tavi.co.uk/TRIPOS.ZIP
> 
> Note the upper case filename!

Thanks, I grabed what was there.  But I guess I was confused.  I was
hoping to get the actual OS but all I see lloking at it is dicments
explaining what it is.  Is the OS still available anywhere or is this
another of those parts of our history that has been lost?

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

On Sat, 29 Nov 2008 19:37:47 UTC, billg999@cs.uofs.edu (Bill Gunshannon)
wrote:

> In article <176uZD2KcidF-pn2-hYI3HRceTyXx@rikki.tavi.co.uk>,
> 	"Bob Eager" <rde42@spamcop.net> writes:
> > On Sat, 29 Nov 2008 16:44:44 UTC, billg999@cs.uofs.edu (Bill Gunshannon)
> > wrote:
> > 
> >> In article <176uZD2KcidF-pn2-vojyydTuUdQK@rikki.tavi.co.uk>,
> >> 	"Bob Eager" <rde42@spamcop.net> writes:
> >> > On Sat, 29 Nov 2008 15:00:38 UTC, Johnny Billquist <bqt@update.uu.se> 
> >> > wrote:
> >> > 
> >> >> I also think that parts of the system in the AMIGA was written in BCPL.
> >> > 
> >> > Yup...it was based on the TRIPOS operating system, written by some 
> >> > undergraduates at the University of Cambridge (UK). I have a copy of 
> >> > TRIPOS somewhere...the source code, anyway. I ran it on a PDP-11 for a 
> >> > while, after patching the kernel image so it would work on an 11/34!
> >> 
> >> Any chance of getting the PDP-11 stuff?  Some of us still enjoy playing
> >> with ours and I never heard anyone mention this OS.
> > 
> > OK...
> > 
> >    www.tavi.co.uk/TRIPOS.ZIP
> > 
> > Note the upper case filename!
> 
> Thanks, I grabed what was there.  But I guess I was confused.  I was
> hoping to get the actual OS but all I see lloking at it is dicments
> explaining what it is.  Is the OS still available anywhere or is this
> another of those parts of our history that has been lost?

I was in a rush...it was dinner time! There are two other ZIP files, 
look as if they are literally the files off the original distribution 
tape. There are a number of files, called (usefully) f1, f2, ... This 
isn't as bad as it sounds, as one of the files in TAPE2 appears to be an
index.

Each file is often a composite file (think '.TLB kind of thing) which is
easily decoded (probably even in DCL!).

Disappointingly, I can't at first glance see a PDP-11 kernel...but I may
be wrong.

Files:

  http://www.tavi.co.uk/TAPE1.ZIP
  http://www.tavi.co.uk/TAPE2.ZIP


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

On 2008-11-29, Richard B. Gilbert <rgilbert88@comcast.net> wrote:
> Errr.....  I thought we were talking about Macro-32 here.  Has someone 
> ported Linux to the VAX?

http://linux-vax.sourceforge.net/

I'm not seeing any news newer than 2006, though.
-- 
roger ivie
rivie@ridgenet.net

Bill Gunshannon wrote:
> Ah yes, Ada.  I remember hearing about all the bad things that C does
> that Ada doesn't, which is what made Ada so superior.  Until you look
> at the last chapter of the Ada textbook they used here that basicly
> showed how to get around all that string typecasting stiff.  :-)  And
> all kinds of other dirty little tricks that someone decided really were
> necesary writing programs in the real world.

There is a big difference between allowing the dirty stuff by
special means and allowing it generally.

C++ asm and C# unsafe is not bad in my book, because they
are clearly identifiable as dirty.

> OK.  But what about storing 6 ASCII characters packed into one REAL*4
> variable?  :-)

Not possible in general. There are 128^6 possible combinations
of bits in 6 ASCII characters and 256^4 possible combinations of
bits in a REAL*4.

Arne

Richard B. Gilbert wrote:
> Arne Vajh�j wrote:
>> Richard B. Gilbert wrote:
>>> Arne Vajh�j wrote:
>>>> Richard B. Gilbert wrote:
>>>>> As for Linux, which platform did you have in mind?
>>>>
>>>> I guess all of them use the same tool chain. GCC.
>>>>
>>>>> Don't the various Linux versions support their own assemblers?
>>>>
>>>> Yep.
>>>>
>>>> If you save the file as .s then gcc should assemble it.
>>>
>>> Errr.....  I thought we were talking about Macro-32 here.  Has 
>>> someone ported Linux to the VAX?  Why would anyone want to run Linux 
>>> on a VAX when they could run VMS?????
>>
>> We were talking about whether Linux had its own assembler
>> (with the impact of porting Macro-32 to Linux not making
>> any sense).
> 
> The whole thread seems sort of senseless.  It's not VMS related. . . .

The only VMS relevance for this subthread is the fact that
Macro-32 would be ported from VMS.

I don't see the point, but JF brought it up.

Arne

Bill Gunshannon wrote:
> In article <493175dd$0$90262$14726298@news.sunsite.dk>,
> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>> Bill Gunshannon wrote:
>>> In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>,
>>> 	"Bob Eager" <rde42@spamcop.net> writes:
>>>> On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
>>>>
>>>>> Bill Gunshannon wrote:
>>>>>> In article <ggqcj2$ken$1@aioe.org>,
>>>>>> 	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>>>>> Arne Vajhj wrote:
>>>>>>>
>>>>>>>> C Kermit is from around 1989-1990. I believe that it
>>>>>>>> took a few years until C-Kermit was stable enough to replace
>>>>>>>> the old VMS Kermit.
>>>>>>> Unix C kermit is older than that.  For other than unix,
>>>>>>> that might be about right.
>>>>>>>
>>>>>> The BLISS version worked just fine as far as I was concerned.
>>>>> The Bliss version was rock solid.
>>>>>
>>>>> But if I remember correctly, then the C version had
>>>>> better performance (due to ability to use larger
>>>>> buffers or something like that).
>>>> And sliding windows....allowing overlap between send and acknowledge.
>>> Too bad there was no one to just add those features to the Bliss
>>> version.  Hmmmm...  Might be fun to try.  Especially for someone
>>> like me who's only experience with Bliss is knowing it's reputation.
>> FDC probably wanted to standardize on C Kermit on all/many platforms
>> (with a few OS specific modules) to lower the burden of
>> maintenance.
> 
> Having provided platforms for compiling and maintenance of some Kermit
> versions as well as having maintained a few myself, I kknow Frank well
> enough that I would bet he would put up a newer version if someone went
> to the trouble of making one.  I have turned in binaries for versions
> of Kermit for machines not able to run C-Kermit, like the PDP-11.

I have no doubt he would.

But if none volunteered then he would prioritize his time.

And if I remember correctlt then he a few times posted to c.o.v/I-V
asking for volunteers for Kermit work without people rushing
in like for a Black Friday sale.

Arne

Arne Vajh�j wrote:

> We were talking about whether Linux had its own assembler
> (with the impact of porting Macro-32 to Linux not making
> any sense).

NO ! Since MACRO is now a programming language which is compiled, and is
available on vax, alpha and that ia64 thing, it has become a
multi-platform low level programming language.

So why not make it available to even more platforms ? If its macro
substitution is second to none, why not make others benefit from it ?

In article <4931bbe6$0$90265$14726298@news.sunsite.dk>,
	Arne Vajh�j <arne@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> Ah yes, Ada.  I remember hearing about all the bad things that C does
>> that Ada doesn't, which is what made Ada so superior.  Until you look
>> at the last chapter of the Ada textbook they used here that basicly
>> showed how to get around all that string typecasting stiff.  :-)  And
>> all kinds of other dirty little tricks that someone decided really were
>> necesary writing programs in the real world.
> 
> There is a big difference between allowing the dirty stuff by
> special means and allowing it generally.
> 
> C++ asm and C# unsafe is not bad in my book, because they
> are clearly identifiable as dirty.

My point was that the Ada advocates (and we used to have a real big
one here) were constantly talking about all the bad features of C and
similar languages.  But then, when it came time to get real, Ada had
to include all those "bad" things in order for the language to do the
things it was intended for like twiddle with real hardware.  If there
is a way to apply the term hypocrite Ada fits the bill.  :-)

> 
>> OK.  But what about storing 6 ASCII characters packed into one REAL*4
>> variable?  :-)
> 
> Not possible in general. There are 128^6 possible combinations
> of bits in 6 ASCII characters and 256^4 possible combinations of
> bits in a REAL*4.

Not possible?  I really expected someone to recognize RAD50 (aka RADIX-50)
when I posted this.  :-)

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

In article <4931bcfa$0$90265$14726298@news.sunsite.dk>,
	=?windows-1252?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> In article <493175dd$0$90262$14726298@news.sunsite.dk>,
>> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>>> Bill Gunshannon wrote:
>>>> In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>,
>>>> 	"Bob Eager" <rde42@spamcop.net> writes:
>>>>> On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
>>>>>
>>>>>> Bill Gunshannon wrote:
>>>>>>> In article <ggqcj2$ken$1@aioe.org>,
>>>>>>> 	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>>>>>> Arne Vajhj wrote:
>>>>>>>>
>>>>>>>>> C Kermit is from around 1989-1990. I believe that it
>>>>>>>>> took a few years until C-Kermit was stable enough to replace
>>>>>>>>> the old VMS Kermit.
>>>>>>>> Unix C kermit is older than that.  For other than unix,
>>>>>>>> that might be about right.
>>>>>>>>
>>>>>>> The BLISS version worked just fine as far as I was concerned.
>>>>>> The Bliss version was rock solid.
>>>>>>
>>>>>> But if I remember correctly, then the C version had
>>>>>> better performance (due to ability to use larger
>>>>>> buffers or something like that).
>>>>> And sliding windows....allowing overlap between send and acknowledge.
>>>> Too bad there was no one to just add those features to the Bliss
>>>> version.  Hmmmm...  Might be fun to try.  Especially for someone
>>>> like me who's only experience with Bliss is knowing it's reputation.
>>> FDC probably wanted to standardize on C Kermit on all/many platforms
>>> (with a few OS specific modules) to lower the burden of
>>> maintenance.
>> 
>> Having provided platforms for compiling and maintenance of some Kermit
>> versions as well as having maintained a few myself, I kknow Frank well
>> enough that I would bet he would put up a newer version if someone went
>> to the trouble of making one.  I have turned in binaries for versions
>> of Kermit for machines not able to run C-Kermit, like the PDP-11.
> 
> I have no doubt he would.
> 
> But if none volunteered then he would prioritize his time.
> 
> And if I remember correctlt then he a few times posted to c.o.v/I-V
> asking for volunteers for Kermit work without people rushing
> in like for a Black Friday sale.

Maybe it's just because my Kermit usage goes all the way back to the
beginning days but I have always offered whatever resources I had
available.  I like Kermit!!  And I still find DOS based Kermit to
be one of the best VT terminals I have ever used.  Not to mention
how many times I have used it to load bootstraps for devices I don't
have the PROM for.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

In article <176uZD2KcidF-pn2-tbM0bBBd7pZJ@rikki.tavi.co.uk>,
	"Bob Eager" <rde42@spamcop.net> writes:
> On Sat, 29 Nov 2008 19:37:47 UTC, billg999@cs.uofs.edu (Bill Gunshannon)
> wrote:
> 
>> In article <176uZD2KcidF-pn2-hYI3HRceTyXx@rikki.tavi.co.uk>,
>> 	"Bob Eager" <rde42@spamcop.net> writes:
>> > On Sat, 29 Nov 2008 16:44:44 UTC, billg999@cs.uofs.edu (Bill Gunshannon)
>> > wrote:
>> > 
>> >> In article <176uZD2KcidF-pn2-vojyydTuUdQK@rikki.tavi.co.uk>,
>> >> 	"Bob Eager" <rde42@spamcop.net> writes:
>> >> > On Sat, 29 Nov 2008 15:00:38 UTC, Johnny Billquist <bqt@update.uu.se> 
>> >> > wrote:
>> >> > 
>> >> >> I also think that parts of the system in the AMIGA was written in BCPL.
>> >> > 
>> >> > Yup...it was based on the TRIPOS operating system, written by some 
>> >> > undergraduates at the University of Cambridge (UK). I have a copy of 
>> >> > TRIPOS somewhere...the source code, anyway. I ran it on a PDP-11 for a 
>> >> > while, after patching the kernel image so it would work on an 11/34!
>> >> 
>> >> Any chance of getting the PDP-11 stuff?  Some of us still enjoy playing
>> >> with ours and I never heard anyone mention this OS.
>> > 
>> > OK...
>> > 
>> >    www.tavi.co.uk/TRIPOS.ZIP
>> > 
>> > Note the upper case filename!
>> 
>> Thanks, I grabed what was there.  But I guess I was confused.  I was
>> hoping to get the actual OS but all I see lloking at it is dicments
>> explaining what it is.  Is the OS still available anywhere or is this
>> another of those parts of our history that has been lost?
> 
> I was in a rush...it was dinner time! There are two other ZIP files, 
> look as if they are literally the files off the original distribution 
> tape. There are a number of files, called (usefully) f1, f2, ... This 
> isn't as bad as it sounds, as one of the files in TAPE2 appears to be an
> index.
> 
> Each file is often a composite file (think '.TLB kind of thing) which is
> easily decoded (probably even in DCL!).
> 
> Disappointingly, I can't at first glance see a PDP-11 kernel...but I may
> be wrong.
> 
> Files:
> 
>   http://www.tavi.co.uk/TAPE1.ZIP
>   http://www.tavi.co.uk/TAPE2.ZIP
 
Leftover turkey?  :-)  Thanks.  I grabbed the rest.  I will look at it
in more detail this week.  Maybe I will be trying to make a boot tape
like I had to do with Ultrix-11 when the pieces first showed up.

bill 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

Bill Gunshannon wrote:
> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>,
> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>> Bill Gunshannon wrote:
>>> OK.  But what about storing 6 ASCII characters packed into one REAL*4
>>> variable?  :-)
>> Not possible in general. There are 128^6 possible combinations
>> of bits in 6 ASCII characters and 256^4 possible combinations of
>> bits in a REAL*4.
> 
> Not possible?  I really expected someone to recognize RAD50 (aka RADIX-50)
> when I posted this.  :-)

What does ASCII have to do with RADIX-50 ?

Arne

Bill Gunshannon wrote:
> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>,
> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>> Bill Gunshannon wrote:
>>> Ah yes, Ada.  I remember hearing about all the bad things that C does
>>> that Ada doesn't, which is what made Ada so superior.  Until you look
>>> at the last chapter of the Ada textbook they used here that basicly
>>> showed how to get around all that string typecasting stiff.  :-)  And
>>> all kinds of other dirty little tricks that someone decided really were
>>> necesary writing programs in the real world.
>> There is a big difference between allowing the dirty stuff by
>> special means and allowing it generally.
>>
>> C++ asm and C# unsafe is not bad in my book, because they
>> are clearly identifiable as dirty.
> 
> My point was that the Ada advocates (and we used to have a real big
> one here) were constantly talking about all the bad features of C and
> similar languages.  But then, when it came time to get real, Ada had
> to include all those "bad" things in order for the language to do the
> things it was intended for like twiddle with real hardware.  If there
> is a way to apply the term hypocrite Ada fits the bill.  :-)

As long as it is clearly identifiable as bing the dirty stuff, then
I don't see a problem or any hypocracy.

But without you explaining what Ada tricks you are talking about,
then it is hard to tell.

I have given two examples from C++ and C# of what I mean.

My Ada skills are not good enough to guess what you are talking
about. Probably I have only learned the nice Ada (and what I
did learn looked very nice indeeed).

Arne

Bill Gunshannon wrote:
> In article <493175dd$0$90262$14726298@news.sunsite.dk>,
> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>> Bill Gunshannon wrote:
>>> In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>,
>>> 	"Bob Eager" <rde42@spamcop.net> writes:
>>>> On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
>>>>
>>>>> Bill Gunshannon wrote:
>>>>>> In article <ggqcj2$ken$1@aioe.org>,
>>>>>> 	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>>>>> Arne Vajhj wrote:
>>>>>>>
>>>>>>>> C Kermit is from around 1989-1990. I believe that it
>>>>>>>> took a few years until C-Kermit was stable enough to replace
>>>>>>>> the old VMS Kermit.
>>>>>>> Unix C kermit is older than that.  For other than unix,
>>>>>>> that might be about right.
>>>>>>>
>>>>>> The BLISS version worked just fine as far as I was concerned.
>>>>> The Bliss version was rock solid.
>>>>>
>>>>> But if I remember correctly, then the C version had
>>>>> better performance (due to ability to use larger
>>>>> buffers or something like that).
>>>> And sliding windows....allowing overlap between send and acknowledge.
>>> Too bad there was no one to just add those features to the Bliss
>>> version.  Hmmmm...  Might be fun to try.  Especially for someone
>>> like me who's only experience with Bliss is knowing it's reputation.
>> FDC probably wanted to standardize on C Kermit on all/many platforms
>> (with a few OS specific modules) to lower the burden of
>> maintenance.
> 
> Having provided platforms for compiling and maintenance of some Kermit
> versions as well as having maintained a few myself, I kknow Frank well
> enough that I would bet he would put up a newer version if someone went
> to the trouble of making one.  I have turned in binaries for versions
> of Kermit for machines not able to run C-Kermit, like the PDP-11.
> 

Frank has always, AFAIK, given credit where credit was due.  I once 
wrote a page or two on using Kermit with VMS.  Frank used part of it, 
with my permission, in one his books and gave me proper credit.  This 
was back in the 1990s or, perhaps, the very late 1980s.

On Sat, 29 Nov 2008 22:44:25 UTC, billg999@cs.uofs.edu (Bill Gunshannon)
wrote:

> Leftover turkey?  :-)  Thanks.  I grabbed the rest.  I will look at it
> in more detail this week.  Maybe I will be trying to make a boot tape
> like I had to do with Ultrix-11 when the pieces first showed up.

If it has missing bits, let me know. Although I think that's all I had. 
I have a PDP-11 compiler for BCPL somewhere, but it's for UNIX...

No, not leftover turkey. Wrong side of the pond...

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

On Sat, 29 Nov 2008 22:38:37 UTC, billg999@cs.uofs.edu (Bill Gunshannon)
wrote:

> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>,
> 	Arne Vajhj <arne@vajhoej.dk> writes:
> > Bill Gunshannon wrote:
> >> Ah yes, Ada.  I remember hearing about all the bad things that C does
> >> that Ada doesn't, which is what made Ada so superior.  Until you look
> >> at the last chapter of the Ada textbook they used here that basicly
> >> showed how to get around all that string typecasting stiff.  :-)  And
> >> all kinds of other dirty little tricks that someone decided really were
> >> necesary writing programs in the real world.
> > 
> > There is a big difference between allowing the dirty stuff by
> > special means and allowing it generally.
> > 
> > C++ asm and C# unsafe is not bad in my book, because they
> > are clearly identifiable as dirty.
> 
> My point was that the Ada advocates (and we used to have a real big
> one here) were constantly talking about all the bad features of C and
> similar languages.  But then, when it came time to get real, Ada had
> to include all those "bad" things in order for the language to do the
> things it was intended for like twiddle with real hardware.  If there
> is a way to apply the term hypocrite Ada fits the bill.  :-)
> 
> > 
> >> OK.  But what about storing 6 ASCII characters packed into one REAL*4
> >> variable?  :-)
> > 
> > Not possible in general. There are 128^6 possible combinations
> > of bits in 6 ASCII characters and 256^4 possible combinations of
> > bits in a REAL*4.
> 
> Not possible?  I really expected someone to recognize RAD50 (aka RADIX-50)
> when I posted this.  :-)

I recognised it...just didn't get round to saying anything. And anyway, 
some pedant would have pointed out that RAD50 only contains part of the 
ASCII set and thus isn't ASCII.... Oh, the joys
of RAD50 conversion in PDP-11 assembler...

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

JF Mezei wrote:
> Arne Vajh�j wrote:
>> We were talking about whether Linux had its own assembler
>> (with the impact of porting Macro-32 to Linux not making
>> any sense).
> 
> NO ! Since MACRO is now a programming language which is compiled, and is
> available on vax, alpha and that ia64 thing, it has become a
> multi-platform low level programming language.

You can say that.

But if you do not have existing code base in the language then
I can see no reason why to start writing code in such a language.

It does not make sense for general programming and if they needed
direct instruction access then Macro-32 would not supply it and
assemblers already exists.

> So why not make it available to even more platforms ? If its macro
> substitution is second to none, why not make others benefit from it ?

You mean that since the Macro-32 capabilities are so great that
people on VMS prefer it over HLL for VMS programming then developers
on other platforms would do the same ?

I see one huge problem with that reason !

Arne

On Sat, 29 Nov 2008 23:12:15 UTC, "Richard B. Gilbert" 
<rgilbert88@comcast.net> wrote:

> Bill Gunshannon wrote:
> > In article <493175dd$0$90262$14726298@news.sunsite.dk>,
> > 	Arne Vajhj <arne@vajhoej.dk> writes:
> >> Bill Gunshannon wrote:
> >>> In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>,
> >>> 	"Bob Eager" <rde42@spamcop.net> writes:
> >>>> On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
> >>>>
> >>>>> Bill Gunshannon wrote:
> >>>>>> In article <ggqcj2$ken$1@aioe.org>,
> >>>>>> 	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> >>>>>>> Arne Vajhj wrote:
> >>>>>>>
> >>>>>>>> C Kermit is from around 1989-1990. I believe that it
> >>>>>>>> took a few years until C-Kermit was stable enough to replace
> >>>>>>>> the old VMS Kermit.
> >>>>>>> Unix C kermit is older than that.  For other than unix,
> >>>>>>> that might be about right.
> >>>>>>>
> >>>>>> The BLISS version worked just fine as far as I was concerned.
> >>>>> The Bliss version was rock solid.
> >>>>>
> >>>>> But if I remember correctly, then the C version had
> >>>>> better performance (due to ability to use larger
> >>>>> buffers or something like that).
> >>>> And sliding windows....allowing overlap between send and acknowledge.
> >>> Too bad there was no one to just add those features to the Bliss
> >>> version.  Hmmmm...  Might be fun to try.  Especially for someone
> >>> like me who's only experience with Bliss is knowing it's reputation.
> >> FDC probably wanted to standardize on C Kermit on all/many platforms
> >> (with a few OS specific modules) to lower the burden of
> >> maintenance.
> > 
> > Having provided platforms for compiling and maintenance of some Kermit
> > versions as well as having maintained a few myself, I kknow Frank well
> > enough that I would bet he would put up a newer version if someone went
> > to the trouble of making one.  I have turned in binaries for versions
> > of Kermit for machines not able to run C-Kermit, like the PDP-11.
> > 
> 
> Frank has always, AFAIK, given credit where credit was due.  I once 
> wrote a page or two on using Kermit with VMS.  Frank used part of it, 
> with my permission, in one his books and gave me proper credit.  This 
> was back in the 1990s or, perhaps, the very late 1980s.

Yup, I was credited for my little contributiion for DOS Kermit, which I 
bet someone here has used.

It was a resident program to make NUM LOCK usable as a GOLD key...
-- 
Bob Eager
Use the BIG mirror service in the UK:
http://www.mirrorservice.org

On Sat, 29 Nov 2008 23:17:51 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:

> You mean that since the Macro-32 capabilities are so great that
> people on VMS prefer it over HLL for VMS programming then developers
> on other platforms would do the same ?

Well, I can see that its macro facilities are good enough to make it a 
fair meta-assembler if required. But it's still not a strong macro 
processor compared to a standalone one - it requires fixed fields, 
generally works a line at a time, there are restrictions on macro names,
you can't have variable delimiters...

But I still like it a lot!

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

Bill Gunshannon wrote:
> In article <TsCdnSQAcecj4KzUnZ2dnUVZ_oPinZ2d@giganews.com>,
> 	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> Arne Vajh�j wrote:
>>> Richard B. Gilbert wrote:
>>>> As for Linux, which platform did you have in mind?
>>> I guess all of them use the same tool chain. GCC.
>>>
>>>> Don't the various Linux versions support their own assemblers?
>>> Yep.
>>>
>>> If you save the file as .s then gcc should assemble it.
>>>
>>> Arne
>> Errr.....  I thought we were talking about Macro-32 here.  Has someone 
>> ported Linux to the VAX?  
> 
> While it doesn't appear to have seen much (any?) activity in almost three
> years, the answer is yes.
> 
>>                           Why would anyone want to run Linux on a VAX 
>> when they could run VMS?????
> 
> Rhetorical question, right?  Running VMS means working with a whole
> different animal.  A more reasonable question would be, "Why would
> anyone want to run Linux on a VAX when it's just a poor stepchild
> to Unix and there are several excelent versions of Unix availble?" :-)

One might equally ask why would anybody want to run Unix on a VAX!
Clearly there must be some reason since DEC released Ultrix for VAX
and there were unsupported (by DEC) ports of various flavors of Unix.

There are things that can be done most easily under Unix but I wouldn't 
waste a VAX on it.  I waste a couple of SPARC boxes on it!

Imagine if Macro-32 were ported to OS-X.

Mr VAXman would be *really* happy.

And in the end, isn't it the goal of VMS engineering to try to make Mr
VAXman happy because when he is happy, it means that all other customers
are happy ?

Bob Eager wrote:
> On Sat, 29 Nov 2008 23:17:51 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
>> You mean that since the Macro-32 capabilities are so great that
>> people on VMS prefer it over HLL for VMS programming then developers
>> on other platforms would do the same ?
> 
> Well, I can see that its macro facilities are good enough to make it a 
> fair meta-assembler if required. But it's still not a strong macro 
> processor compared to a standalone one - it requires fixed fields, 
> generally works a line at a time, there are restrictions on macro names,
> you can't have variable delimiters...
> 
> But I still like it a lot!

I wrote about 30000 lines of it in the the last half of the 80's
(a little bit into the early 90's).

I like it. I can still write simple code in it, so many years after.

But I don't see any future for it except keeping the existing
code compilable on platforms with VMS.

Arne

JF Mezei wrote:
> Imagine if Macro-32 were ported to OS-X.
> 
> Mr VAXman would be *really* happy.
> 
> And in the end, isn't it the goal of VMS engineering to try to make Mr
> VAXman happy because when he is happy, it means that all other customers
> are happy ?

I don't think so.

He is significantly above the average.

Arne

In article <0021061e$0$6670$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
>Imagine if Macro-32 were ported to OS-X.
>
>Mr VAXman would be *really* happy.

I might be mildly amused.  I'm suffering C on both OS X and Linux as
well as a few other lingos.  Most of the Linux has baan web stuff in
PHP, SQL, etc. but I did recently mention to John Reagan that I was
very impressed at the code the C compiler produced on VMS Itanium as
compared to the gcc compiler on Linux Itanium.  Way way way too many
stops with the gcc compiler.


>And in the end, isn't it the goal of VMS engineering to try to make Mr
>VAXman happy because when he is happy, it means that all other customers
>are happy ?

Wow.  I didn't know that I was such an important metric in the goals
of VMS engineering. :)  Hey VMS guys, keep me happy; keep VMS alive.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker      VAXman(at)TMESIS(dot)COM

.... pejorative statements of opinion are entitled to constitutional protection
no matter how extreme, vituperous, or vigorously expressed they may be. (NJSC)

Copr. 2008 Brian Schenkenberger.  Publication of _this_ usenet article outside
of usenet _must_ include its contents in its entirety including this copyright
notice, disclaimer and quotations.

Arne Vajh�j wrote:
> Bill Gunshannon wrote:
>> Ah yes, Ada.  I remember hearing about all the bad things that C does
>> that Ada doesn't, which is what made Ada so superior.  Until you look
>> at the last chapter of the Ada textbook they used here that basicly
>> showed how to get around all that string typecasting stiff.  :-)  And
>> all kinds of other dirty little tricks that someone decided really were
>> necesary writing programs in the real world.
> 
> There is a big difference between allowing the dirty stuff by
> special means and allowing it generally.
> 
> C++ asm and C# unsafe is not bad in my book, because they
> are clearly identifiable as dirty.
> 
>> OK.  But what about storing 6 ASCII characters packed into one REAL*4
>> variable?  :-)
> 
> Not possible in general. There are 128^6 possible combinations
> of bits in 6 ASCII characters and 256^4 possible combinations of
> bits in a REAL*4.
> 
> Arne

If you really limit your character set, you can do better.  A six bit 
code is sufficient to give you the alphabet, the decimal digits, and 
common punctuation with a few characters left over.  The old, old, OLD,
model 19 and model 26 teletypes used a five bit code!  Two of those 
codes were "Letter Shift", and "Number Shift" which allowed 62 
characters including *stunts" like carriage return, linefeed, bell. . . .

I would add that a clean design does much to alleviate the need for 
"dirty" code!

"Clean" code is so much easier to work with. . . .



It's not clear to me that there is any point in packing six characters 
into a "REAL*4".

On Sun, 30 Nov 2008 01:19:52 UTC, "Richard B. Gilbert" 
<rgilbert88@comcast.net> wrote:

> If you really limit your character set, you can do better.  A six bit 
> code is sufficient to give you the alphabet, the decimal digits, and 
> common punctuation with a few characters left over.

It was good enough dor the PDP-8....!

>  The old, old, OLD,
> model 19 and model 26 teletypes used a five bit code!  Two of those 
> codes were "Letter Shift", and "Number Shift" which allowed 62 
> characters including *stunts" like carriage return, linefeed, bell. . . .

I have some code that generates large message tables that use a six bit 
code, and the code to retrieve them (there was a good reason at the 
time). I used the same approach stolen from teletypes, including a shift
code.

ISTR the ICL 1900 mainframes used three different shift characters, two 
'sticky' and one to sift just the next character into yet another range.
That was basically 6 bit, being a 24 bit machine.


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

Richard B. Gilbert wrote:
> Arne Vajh�j wrote:
>> Bill Gunshannon wrote:
>>> Ah yes, Ada.  I remember hearing about all the bad things that C does
>>> that Ada doesn't, which is what made Ada so superior.  Until you look
>>> at the last chapter of the Ada textbook they used here that basicly
>>> showed how to get around all that string typecasting stiff.  :-)  And
>>> all kinds of other dirty little tricks that someone decided really were
>>> necesary writing programs in the real world.
>>
>> There is a big difference between allowing the dirty stuff by
>> special means and allowing it generally.
>>
>> C++ asm and C# unsafe is not bad in my book, because they
>> are clearly identifiable as dirty.
>>
>>> OK.  But what about storing 6 ASCII characters packed into one REAL*4
>>> variable?  :-)
>>
>> Not possible in general. There are 128^6 possible combinations
>> of bits in 6 ASCII characters and 256^4 possible combinations of
>> bits in a REAL*4.
> 
> If you really limit your character set, you can do better.

Sure. But it ASCII is not within those limits.

>                                                         A six bit 
> code is sufficient to give you the alphabet, the decimal digits, and 
> common punctuation with a few characters left over.

 > It's not clear to me that there is any point in packing six characters
 > into a "REAL*4".

There are not room for 6 codes of 6 bit in 4 byte either.

That only gives 5.33 bit per character.

Arne

On Nov 29, 3:32=A0pm, Johnny Billquist <b...@update.uu.se> wrote:
> johnwalla...@yahoo.co.uk skrev:
>
>
>
> > On Nov 28, 12:54 am, Roger Ivie <ri...@ridgenet.net> wrote:
> >> On 2008-11-27, johnwalla...@yahoo.co.uk <johnwalla...@yahoo.co.uk> wro=
te:
>
> >>> Now if you'd said the National
> >>> Semiconductor NS16000 had been inspired by VAX with the additional
> >>> design goals of modernisation, removal of cruft, and simple support
> >>> for ROMable code, I'd have agreed with that.
> >> Pfft. I've never understood how people can say that when the NS16000
> >> doesn't even have the PC as a general-purpose register.
> >> --
> >> roger ivie
> >> ri...@ridgenet.net
>
> > NS16000 wasn't a VAX clone (the Russians did those, right?), it wasn't
> > even trying to be VAX compatible, but chunks of it might well have
> > been VAX-inspired. Anyway, if you can still achieve all the relevant
> > addressing modes using PC-relative addressing, module pointers, etc,
> > which iirc the NS16000 could, what do you actually lose by not having
> > the PC as a general register? (or is it my turn for a sense of humour
> > failure?) Obviously you can't do the usual party tricks like MOV -
> > (R7), -(R7) like some PDP11s could, but so what? Anyway, history has
> > shown that a nice instruction set architecture is not necessarily
> > guarantee of, or even a prerequisite for, market success. Not then,
> > not now.
>
> The big point of having the PC as a general register is that you don't ne=
ed
> special opcodes for the instructions when you want to address things
> PC-relative. It's just a normal addressing mode, with a general register.
> It makes a lot of things easier. But sure, you can accomplish the same th=
ing
> without that feature. But it makes life more difficult.
>
> Let me give you an example:
> The 68K are pretty inspired by the PDP11 and VAX. But they don't have the=
 PC as
> a general register. Instead you have specific opcodes for variations of t=
he
> instruction. Take CMP (compare) - in the 68K you have compare, and you ha=
ve
> compare immediate.
> In an assembler, you'd write
>
> =A0 =A0 =A0 =A0 CMP.B =A0 #'A,D0
>
> for instance. And the assembler would know that that's actually a special
> version of CMP.B, which takes one immediate argument, and one (data) regi=
ster.
> If you instead wrote
>
> =A0 =A0 =A0 =A0 CMP.B =A0 D0,D1
>
> it would assemble to another opcode.
>
> And you might say "so what". That's all the responsobility of the assembl=
er, and
> I as a programmer don't have to worry or think about it. And it causes th=
e same
> end result as if you would have programmed on a PDP11 or a VAX.
>
> All very true. But consider this. On a PDP11 or a VAX, you could also hav=
e
> written this:
>
> =A0 =A0 =A0 =A0 CMPB =A0 =A0R0,#'A
>
> and you just can't do that on a 68K. The immediate mode argument can only=
 be the
> first argument, since it's actually a different opcode, and not a generic
> argument to the CMPB instruction (or CMP.B as it would be called on a 68K=
).
>
> And no, it's not the same. While one can be replaced by the other, they w=
ill
> cause different results in the condition codes, and code following it wil=
l have
> to be adjusted accordingly. And if you write in assembler, you would prob=
ably
> prefer the code to reflect your through instead of having to be adjusted =
to fit
> into what can be expressed by the instruction set.
>
> There are a whole bunch of variations that can't be expressed because the=
 68K
> have several different opcodes for CMP which caters to various special
> situations. It's all a *mess*!
>
> > I think Ritchie's in-depth history of C (http://cm.bell-labs.com/cm/cs/
> > who/dmr/chist.html) says the auto-increment/auto-decrement stuff came
> > from PDP7.
>
> I doubt it. The PDP7 don't stuff like that, and besides, C wasn't designe=
d until
> they had moved to the PDP-11. The first few versions of Unix on the PDP-1=
1 was
> still written in assembler before they moved to C.
>
> But Ritche have also been very clear that the autoincrement and autodecre=
ment
> elements in C were *not* inspired by the PDP-11.
>
> =A0 =A0 =A0 =A0 Johnny
>
> --
> Johnny Billquist =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|| "I'm on a bus
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0||=
 =A0on a psychedelic trip
> email: b...@softjar.se =A0 =A0 =A0 =A0 =A0 =A0 || =A0Reading murder books
> pdp is alive! =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 || =A0tryin' to sta=
y hip" - B. Idol

Thank you for that. As luck would have it, I'm personally well aware
that the 68K didn't/doesn't do PC-relative addressing of any form,
which as you point out can be considered a bit of a limitation. But
the NS16000 isn't a 68K, it had few of the sillinesses of the 68K and
much of the goodness of the VAX. My recollection is that anything you
could do with PC-relative addressing, you could do on the NS16000 (eg
position-independent ROMable code, and more). Iirc the NS16000 did PC-
relative addressing transparently to the user, without needing special
instructions and without needing the PC as a typical general register,
it did it by using a dedicated PC-relative addressing mode, but I
can't be sure without digging out my books. In addition to the PC-
relative addressing mode it definitely also had something called
(iirc) a module pointer, which could be used to achieve similar
results.

Wrt the relationship between PDP7 and C: I'm not going to attempt to
summarise the relevant bit of a long story in Ritchie's article again.
If you disagree with bits of my previous summary, please read what
Ritchie wrote (it's compatible with most of what you wrote, apart
perhaps from the PDP7 bit).

=?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:

>Richard B. Gilbert wrote:

>>                                                         A six bit 
>> code is sufficient to give you the alphabet, the decimal digits, and 
>> common punctuation with a few characters left over.

> > It's not clear to me that there is any point in packing six characters
> > into a "REAL*4".

>There are not room for 6 codes of 6 bit in 4 byte either.

>That only gives 5.33 bit per character.

RAD50 gives a character set of 40 characters (50 octal).  That's the 
letters A-Z uppercase, digits 0-9, space, two other punctuation characters
and one code which I think was never defined.  I believe this is how PDP-11
operating systems stored file names (a 6.3 name with an implicit period
could be stored as 3 words/6 bytes).

On Sun, 30 Nov 2008 14:16:04 UTC, moroney@world.std.spaamtrap.com 
(Michael Moroney) wrote:

> =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
> 
> >Richard B. Gilbert wrote:
> 
> >>                                                         A six bit 
> >> code is sufficient to give you the alphabet, the decimal digits, and 
> >> common punctuation with a few characters left over.
> 
> > > It's not clear to me that there is any point in packing six characters
> > > into a "REAL*4".
> 
> >There are not room for 6 codes of 6 bit in 4 byte either.
> 
> >That only gives 5.33 bit per character.
> 
> RAD50 gives a character set of 40 characters (50 octal).  That's the 
> letters A-Z uppercase, digits 0-9, space, two other punctuation characters
> and one code which I think was never defined.  I believe this is how PDP-11
> operating systems stored file names (a 6.3 name with an implicit period
> could be stored as 3 words/6 bytes).

I said there'd be a pedant along in a minute! Arne is being the pedant -
saying that it's not ASCII without a full character set...

Yes, I know that RT-11 and DOS/BATCH (who remembers DOS/BATCH?) stored 
filenames in RAD50. And I think MACRO-11 stored symbols like that.

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

Michael Moroney wrote:
> =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>> Richard B. Gilbert wrote:
>>>                                                         A six bit 
>>> code is sufficient to give you the alphabet, the decimal digits, and 
>>> common punctuation with a few characters left over.
> 
>>> It's not clear to me that there is any point in packing six characters
>>> into a "REAL*4".
> 
>> There are not room for 6 codes of 6 bit in 4 byte either.
> 
>> That only gives 5.33 bit per character.
> 
> RAD50 gives a character set of 40 characters (50 octal).  That's the 
> letters A-Z uppercase, digits 0-9, space, two other punctuation characters
> and one code which I think was never defined.

I am able to lookup RADIX-50.

The point is that 2^5.33 is 40.2 (I think it is 40.3 without
the two decimal rounding).

So the 40 characters matches exactly with the requirement to
store 6 characters in 4 bytes.

Arne

On Sun, 30 Nov 2008 14:54:59 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:

> Michael Moroney wrote:
> > =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
> >> Richard B. Gilbert wrote:
> >>>                                                         A six bit 
> >>> code is sufficient to give you the alphabet, the decimal digits, and 
> >>> common punctuation with a few characters left over.
> > 
> >>> It's not clear to me that there is any point in packing six characters
> >>> into a "REAL*4".
> > 
> >> There are not room for 6 codes of 6 bit in 4 byte either.
> > 
> >> That only gives 5.33 bit per character.
> > 
> > RAD50 gives a character set of 40 characters (50 octal).  That's the 
> > letters A-Z uppercase, digits 0-9, space, two other punctuation characters
> > and one code which I think was never defined.
> 
> I am able to lookup RADIX-50.
> 
> The point is that 2^5.33 is 40.2 (I think it is 40.3 without
> the two decimal rounding).
> 
> So the 40 characters matches exactly with the requirement to
> store 6 characters in 4 bytes.

Yes...DEC did that calculation about 40 years ago!

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

In article <4931cb5a$0$90270$14726298@news.sunsite.dk>,
	Arne Vajh�j <arne@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>,
>> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>>> Bill Gunshannon wrote:
>>>> OK.  But what about storing 6 ASCII characters packed into one REAL*4
>>>> variable?  :-)
>>> Not possible in general. There are 128^6 possible combinations
>>> of bits in 6 ASCII characters and 256^4 possible combinations of
>>> bits in a REAL*4.
>> 
>> Not possible?  I really expected someone to recognize RAD50 (aka RADIX-50)
>> when I posted this.  :-)
> 
> What does ASCII have to do with RADIX-50 ?
 
It's all about ASCII.

DUMP /X : Output RAD50 characters

SYSLIB CALLS:

IRAD50 - n = IRAD50(icnt,input,output)
     Converts ASCII characters to RAD50, returning the number of characters
     conerted.
R50ASC - CALL R50ASC(icnt,input,output)
     Converst RAD50 characters to ASCII.
RAD50 - n = RAD50(input)
     Converts six ASCII characters, returning a REAL*4 result which is the
     2-word RAD50 value.

Think RT-11 Filenames......

Or, just lookup RADIX-50 on wiki.

Sometimes it's fun being a dinosaur.  :-)

bill


-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

In article <4931cc41$0$90272$14726298@news.sunsite.dk>,
	Arne Vajh�j <arne@vajhoej.dk> writes:
> Bill Gunshannon wrote:
>> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>,
>> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>>> Bill Gunshannon wrote:
>>>> Ah yes, Ada.  I remember hearing about all the bad things that C does
>>>> that Ada doesn't, which is what made Ada so superior.  Until you look
>>>> at the last chapter of the Ada textbook they used here that basicly
>>>> showed how to get around all that string typecasting stiff.  :-)  And
>>>> all kinds of other dirty little tricks that someone decided really were
>>>> necesary writing programs in the real world.
>>> There is a big difference between allowing the dirty stuff by
>>> special means and allowing it generally.
>>>
>>> C++ asm and C# unsafe is not bad in my book, because they
>>> are clearly identifiable as dirty.
>> 
>> My point was that the Ada advocates (and we used to have a real big
>> one here) were constantly talking about all the bad features of C and
>> similar languages.  But then, when it came time to get real, Ada had
>> to include all those "bad" things in order for the language to do the
>> things it was intended for like twiddle with real hardware.  If there
>> is a way to apply the term hypocrite Ada fits the bill.  :-)
> 
> As long as it is clearly identifiable as bing the dirty stuff, then
> I don't see a problem or any hypocracy.
> 
> But without you explaining what Ada tricks you are talking about,
> then it is hard to tell.
> 
> I have given two examples from C++ and C# of what I mean.
> 
> My Ada skills are not good enough to guess what you are talking
> about. Probably I have only learned the nice Ada (and what I
> did learn looked very nice indeeed).

Anything that can be done in C can be done in Ada.  Including things
like pointer arithmetic, character arithmetic and shifting data between
data types.  The main point being that while people complained about
the dangers of a language that could do these things when it came down
to real world (and, especially real time) programming, they wre necessary
evils.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

Bill Gunshannon wrote:
> In article <4931cb5a$0$90270$14726298@news.sunsite.dk>,
> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>> Bill Gunshannon wrote:
>>> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>,
>>> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>>>> Bill Gunshannon wrote:
>>>>> OK.  But what about storing 6 ASCII characters packed into one REAL*4
>>>>> variable?  :-)
>>>> Not possible in general. There are 128^6 possible combinations
>>>> of bits in 6 ASCII characters and 256^4 possible combinations of
>>>> bits in a REAL*4.
>>> Not possible?  I really expected someone to recognize RAD50 (aka RADIX-50)
>>> when I posted this.  :-)
>> What does ASCII have to do with RADIX-50 ?
>  
> It's all about ASCII.
> 
> DUMP /X : Output RAD50 characters
> 
> SYSLIB CALLS:
> 
> IRAD50 - n = IRAD50(icnt,input,output)
>      Converts ASCII characters to RAD50, returning the number of characters
>      conerted.
> R50ASC - CALL R50ASC(icnt,input,output)
>      Converst RAD50 characters to ASCII.
> RAD50 - n = RAD50(input)
>      Converts six ASCII characters, returning a REAL*4 result which is the
>      2-word RAD50 value.
> 
> Think RT-11 Filenames......
> 
> Or, just lookup RADIX-50 on wiki.
> 
> Sometimes it's fun being a dinosaur.  :-)

The fact that RADIX-50 characters can be converted to and
from ASCII does not make them ASCII.

Arne

John Reagan wrote:
> "Michael Kraemer" <M.Kraemer@gsi.de> wrote in message 
> news:ggljto$85k$00$2@news.t-online.com...
>> Richard B. Gilbert schrieb:
>>
>>> Assembler language programming is just about dead.  The only time it's 
>>> really necessary is when you are bootstrapping a new hardware platform. 
>>> Even device drivers are now written in C.
>> Not every CPU instruction has an equivalent HL construct.
>> Think of byte swapping or "compare & swap" and friends.
>>
>>
> 
> Our C compiler (and BLISS and Pascal) have builtins to let you access such 
> atomic sequences.  You don't need asm() and you don't need to write in 
> assembler.
> 
> On I64, the only place where assembler makes sense is where you are way 
> outside the Calling Standard doing argument shuffling.  VMS' exception 
> handling comes to mind.
> 

So does the internal jacketing done by TIE when going from the
VAX or Alpha to Itanium environments and back the other way.

Tim.

Bill Gunshannon wrote:
> In article <4931cc41$0$90272$14726298@news.sunsite.dk>,
> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>> Bill Gunshannon wrote:
>>> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>,
>>> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>>>> Bill Gunshannon wrote:
>>>>> Ah yes, Ada.  I remember hearing about all the bad things that C does
>>>>> that Ada doesn't, which is what made Ada so superior.  Until you look
>>>>> at the last chapter of the Ada textbook they used here that basicly
>>>>> showed how to get around all that string typecasting stiff.  :-)  And
>>>>> all kinds of other dirty little tricks that someone decided really were
>>>>> necesary writing programs in the real world.
>>>> There is a big difference between allowing the dirty stuff by
>>>> special means and allowing it generally.
>>>>
>>>> C++ asm and C# unsafe is not bad in my book, because they
>>>> are clearly identifiable as dirty.
>>> My point was that the Ada advocates (and we used to have a real big
>>> one here) were constantly talking about all the bad features of C and
>>> similar languages.  But then, when it came time to get real, Ada had
>>> to include all those "bad" things in order for the language to do the
>>> things it was intended for like twiddle with real hardware.  If there
>>> is a way to apply the term hypocrite Ada fits the bill.  :-)
>> As long as it is clearly identifiable as bing the dirty stuff, then
>> I don't see a problem or any hypocracy.
>>
>> But without you explaining what Ada tricks you are talking about,
>> then it is hard to tell.
>>
>> I have given two examples from C++ and C# of what I mean.
>>
>> My Ada skills are not good enough to guess what you are talking
>> about. Probably I have only learned the nice Ada (and what I
>> did learn looked very nice indeeed).
> 
> Anything that can be done in C can be done in Ada.  Including things
> like pointer arithmetic, character arithmetic and shifting data between
> data types.  The main point being that while people complained about
> the dangers of a language that could do these things when it came down
> to real world (and, especially real time) programming, they wre necessary
> evils.

I think that the difference between Ada and C in this regard, is that 
Ada requires that, if you must do "bad" things, you do them in a 
disciplined and documented way.  In C, anything goes.  You can do the 
same things in C and Ada and your C code can be as clear and well 
documented as in Ada.  Sadly, a lot of people do not write C in that 
fashion.

"Man rated" software, that is software that can get someone killed if 
it's wrong, is frequently written in Ada because Ada makes it difficult 
to write poor code.

I doubt that Ada can be written as quickly as C, but when you're done, 
you can have a great deal more confidence that it's done right.

Bill Gunshannon wrote:
> In article <176uZD2KcidF-pn2-Ygioq8GMIEPI@rikki.tavi.co.uk>,
> 	"Bob Eager" <rde42@spamcop.net> writes:
>> On Sat, 29 Nov 2008 16:42:31 UTC, billg999@cs.uofs.edu (Bill Gunshannon)
>> wrote:
>>
>>> In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>,
>>> 	"Bob Eager" <rde42@spamcop.net> writes:
>>>> On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
>>>>
>>>>> Bill Gunshannon wrote:
>>>>>> In article <ggqcj2$ken$1@aioe.org>,
>>>>>> 	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>>>>> Arne Vajhj wrote:
>>>>>>>
>>>>>>>> C Kermit is from around 1989-1990. I believe that it
>>>>>>>> took a few years until C-Kermit was stable enough to replace
>>>>>>>> the old VMS Kermit.
>>>>>>> Unix C kermit is older than that.  For other than unix,
>>>>>>> that might be about right.
>>>>>>>
>>>>>> The BLISS version worked just fine as far as I was concerned.
>>>>> The Bliss version was rock solid.
>>>>>
>>>>> But if I remember correctly, then the C version had
>>>>> better performance (due to ability to use larger
>>>>> buffers or something like that).
>>>> And sliding windows....allowing overlap between send and acknowledge.
>>> Too bad there was no one to just add those features to the Bliss
>>> version.  Hmmmm...  Might be fun to try.  Especially for someone
>>> like me who's only experience with Bliss is knowing it's reputation.
>> The definitions are all in the Kermit protocol book. Probably still 
>> available used.
> 
> I don't think knowledge of Kermit is the problem.  Experience with Bliss
> is another matter entirely.  :-)
> 

I disagree. I am a BLISS programmer. I'm sure I'm about to
be shot down by somebody, but it's my prefered language. I
found it quite easy to use when I started playing with it.
I am aware of it's reputation. However, I don't think it
it is deserved. It's all about the task you want to tackle.
BLISS is incredibly flexible and allows for a very large
degree of control by the programmer. It also has a brilliant
macro language (which has already been pointed out before :-).

Tim.

Richard B. Gilbert wrote:
> Bob Koehler wrote:
>> In article <ggnoeu$idm$1@aioe.org>, Glen Herrmannsfeldt 
>> <gah@ugcs.caltech.edu> writes:
>>> Yes, but C descended from BCPL and B, which were older
>>> than the PDP-11.
>>
>>    Did BCPL or B have ++ and -- operators?  Did they assume byte
>>    addressable memory and a built in stack?
>>
> 
> I suspect that the ONLY way to find out at this point would be to catch 
> Kernighan or Plauger and ask them.  I'm not sure that either language 
> ever escaped from the research laboratories!

B had the auto increment/decrement operators, like C.
 From what I've seen I think it was byte addressable on
the PDP-11. It was word addressable on the Honeywell
6070.

Tim.

On 2008-11-30, johnwallace4@yahoo.co.uk <johnwallace4@yahoo.co.uk> wrote:
> Iirc the NS16000 did PC-
> relative addressing transparently to the user, without needing special
> instructions and without needing the PC as a typical general register,
> it did it by using a dedicated PC-relative addressing mode

Which is precisely the sort of thing that made it not seem VAX-like to
me.

To me, the VAX has always seemed like a good register set with addressing
modes on which instructions have been hung like ornaments. Saying that
something is VAX-like because of its instruction set has always seemed,
to me, to be missing the whole point of the VAX. 
-- 
roger ivie
rivie@ridgenet.net

In article <1r2dnVpZ-e90Kq_UnZ2dnUVZ_obinZ2d@giganews.com>,
	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> Bill Gunshannon wrote:
>> In article <4931cc41$0$90272$14726298@news.sunsite.dk>,
>> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>>> Bill Gunshannon wrote:
>>>> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>,
>>>> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>>>>> Bill Gunshannon wrote:
>>>>>> Ah yes, Ada.  I remember hearing about all the bad things that C does
>>>>>> that Ada doesn't, which is what made Ada so superior.  Until you look
>>>>>> at the last chapter of the Ada textbook they used here that basicly
>>>>>> showed how to get around all that string typecasting stiff.  :-)  And
>>>>>> all kinds of other dirty little tricks that someone decided really were
>>>>>> necesary writing programs in the real world.
>>>>> There is a big difference between allowing the dirty stuff by
>>>>> special means and allowing it generally.
>>>>>
>>>>> C++ asm and C# unsafe is not bad in my book, because they
>>>>> are clearly identifiable as dirty.
>>>> My point was that the Ada advocates (and we used to have a real big
>>>> one here) were constantly talking about all the bad features of C and
>>>> similar languages.  But then, when it came time to get real, Ada had
>>>> to include all those "bad" things in order for the language to do the
>>>> things it was intended for like twiddle with real hardware.  If there
>>>> is a way to apply the term hypocrite Ada fits the bill.  :-)
>>> As long as it is clearly identifiable as bing the dirty stuff, then
>>> I don't see a problem or any hypocracy.
>>>
>>> But without you explaining what Ada tricks you are talking about,
>>> then it is hard to tell.
>>>
>>> I have given two examples from C++ and C# of what I mean.
>>>
>>> My Ada skills are not good enough to guess what you are talking
>>> about. Probably I have only learned the nice Ada (and what I
>>> did learn looked very nice indeeed).
>> 
>> Anything that can be done in C can be done in Ada.  Including things
>> like pointer arithmetic, character arithmetic and shifting data between
>> data types.  The main point being that while people complained about
>> the dangers of a language that could do these things when it came down
>> to real world (and, especially real time) programming, they wre necessary
>> evils.
> 
> I think that the difference between Ada and C in this regard, is that 
> Ada requires that, if you must do "bad" things, you do them in a 
> disciplined and documented way.  In C, anything goes.  You can do the 
> same things in C and Ada and your C code can be as clear and well 
> documented as in Ada.  Sadly, a lot of people do not write C in that 
> fashion.

You are still missing the point.  The anti-C crowd (and I see a lot of
in the academic environment) don't attack the ease of use for those
functions, they specifically att6ack the functions.  Reality is that
the functions are necessary for many tasks.

> 
> "Man rated" software, that is software that can get someone killed if 
> it's wrong, is frequently written in Ada because Ada makes it difficult 
> to write poor code.

One can write poor code in any language and no language prevents or even
hinders it.  Bad code starts long before one reaches the coding phase of
SE.  But then, there really isn't much SE in the business anymore.
It should also be noted that although the USAF was the originator of the
idea for Ada and a strong member of the committee that developed it when
it was done and DOD tried to mandate it they were the first to refuse.
To the best of my knowledge, Wright-Patterson is still using JOVIAL.  :-)

> 
> I doubt that Ada can be written as quickly as C, but when you're done, 
> you can have a great deal more confidence that it's done right.
 
I can write Ada as quickly as I can write C.  But then, for most real
programming projects I get nvolved in the actual coding is only a small
percentage of the time I spend.

bill 

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

Bill Gunshannon wrote:
> In article <1r2dnVpZ-e90Kq_UnZ2dnUVZ_obinZ2d@giganews.com>,
> 	"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> Bill Gunshannon wrote:
>>> In article <4931cc41$0$90272$14726298@news.sunsite.dk>,
>>> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>>>> Bill Gunshannon wrote:
>>>>> In article <4931bbe6$0$90265$14726298@news.sunsite.dk>,
>>>>> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>>>>>> Bill Gunshannon wrote:
>>>>>>> Ah yes, Ada.  I remember hearing about all the bad things that C does
>>>>>>> that Ada doesn't, which is what made Ada so superior.  Until you look
>>>>>>> at the last chapter of the Ada textbook they used here that basicly
>>>>>>> showed how to get around all that string typecasting stiff.  :-)  And
>>>>>>> all kinds of other dirty little tricks that someone decided really were
>>>>>>> necesary writing programs in the real world.
>>>>>> There is a big difference between allowing the dirty stuff by
>>>>>> special means and allowing it generally.
>>>>>>
>>>>>> C++ asm and C# unsafe is not bad in my book, because they
>>>>>> are clearly identifiable as dirty.
>>>>> My point was that the Ada advocates (and we used to have a real big
>>>>> one here) were constantly talking about all the bad features of C and
>>>>> similar languages.  But then, when it came time to get real, Ada had
>>>>> to include all those "bad" things in order for the language to do the
>>>>> things it was intended for like twiddle with real hardware.  If there
>>>>> is a way to apply the term hypocrite Ada fits the bill.  :-)
>>>> As long as it is clearly identifiable as bing the dirty stuff, then
>>>> I don't see a problem or any hypocracy.
>>>>
>>>> But without you explaining what Ada tricks you are talking about,
>>>> then it is hard to tell.
>>>>
>>>> I have given two examples from C++ and C# of what I mean.
>>>>
>>>> My Ada skills are not good enough to guess what you are talking
>>>> about. Probably I have only learned the nice Ada (and what I
>>>> did learn looked very nice indeeed).
>>> Anything that can be done in C can be done in Ada.  Including things
>>> like pointer arithmetic, character arithmetic and shifting data between
>>> data types.  The main point being that while people complained about
>>> the dangers of a language that could do these things when it came down
>>> to real world (and, especially real time) programming, they wre necessary
>>> evils.
>> I think that the difference between Ada and C in this regard, is that 
>> Ada requires that, if you must do "bad" things, you do them in a 
>> disciplined and documented way.  In C, anything goes.  You can do the 
>> same things in C and Ada and your C code can be as clear and well 
>> documented as in Ada.  Sadly, a lot of people do not write C in that 
>> fashion.
> 
> You are still missing the point.  The anti-C crowd (and I see a lot of
> in the academic environment) don't attack the ease of use for those
> functions, they specifically att6ack the functions.  Reality is that
> the functions are necessary for many tasks.
> 
>> "Man rated" software, that is software that can get someone killed if 
>> it's wrong, is frequently written in Ada because Ada makes it difficult 
>> to write poor code.
> 
> One can write poor code in any language and no language prevents or even
> hinders it.  Bad code starts long before one reaches the coding phase of
> SE.  But then, there really isn't much SE in the business anymore.
> It should also be noted that although the USAF was the originator of the
> idea for Ada and a strong member of the committee that developed it when
> it was done and DOD tried to mandate it they were the first to refuse.
> To the best of my knowledge, Wright-Patterson is still using JOVIAL.  :-)
> 
Some languages make it easy to write poor code.  Others make it more 
difficult.

>> I doubt that Ada can be written as quickly as C, but when you're done, 
>> you can have a great deal more confidence that it's done right.
>  
> I can write Ada as quickly as I can write C.  But then, for most real
> programming projects I get nvolved in the actual coding is only a small
> percentage of the time I spend.
> 

As with most things, the DESIGN has a great deal to do with the success 
or failure of the end product!  I'm not sure there is any programming 
language that will do much to compensate for poor design.

A large part of the problem is managers who "want it by Tuesday" right 
or wrong!

On Sun, 30 Nov 2008 18:40:06 UTC, cook@wvnvms.wvnet.edu (George Cook) 
wrote:

> In article <176uZD2KcidF-pn2-o3F974HdWwBP@rikki.tavi.co.uk>, "Bob Eager" <rde42@spamcop.net> writes:
> > On Sun, 30 Nov 2008 14:16:04 UTC, moroney@world.std.spaamtrap.com 
> > (Michael Moroney) wrote:
> > 
> >> =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
> >> 
> >> >Richard B. Gilbert wrote:
> >> 
> >> >>                                                         A six bit 
> >> >> code is sufficient to give you the alphabet, the decimal digits, and 
> >> >> common punctuation with a few characters left over.
> >> 
> >> > > It's not clear to me that there is any point in packing six characters
> >> > > into a "REAL*4".
> >> 
> >> >There are not room for 6 codes of 6 bit in 4 byte either.
> >> 
> >> >That only gives 5.33 bit per character.
> >> 
> >> RAD50 gives a character set of 40 characters (50 octal).  That's the 
> >> letters A-Z uppercase, digits 0-9, space, two other punctuation characters
> >> and one code which I think was never defined.  I believe this is how PDP-11
> >> operating systems stored file names (a 6.3 name with an implicit period
> >> could be stored as 3 words/6 bytes).
> > 
> > I said there'd be a pedant along in a minute! Arne is being the pedant -
> > saying that it's not ASCII without a full character set...
> > 
> > Yes, I know that RT-11 and DOS/BATCH (who remembers DOS/BATCH?) stored 
> > filenames in RAD50. And I think MACRO-11 stored symbols like that.
> 
> I still have my DOS/BATCH handbook.  It's from my first major paid
> programming assignment which was to add RK07 drive support to DOS/BATCH.
> It was actually a pretty neat little OS.

Incredibly small. 2K words resident, with masses of overlays at two 
levels.

I remember having to fix a problem with it on RK05s...I think it 
wouldn't load stuff sometimes due to treating some field as signed when 
it should have been unsigned. I know we had a very bad printout of the 
source code. Anyway, I fixed it...

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

In article <176uZD2KcidF-pn2-o3F974HdWwBP@rikki.tavi.co.uk>, "Bob Eager" <rde42@spamcop.net> writes:
> On Sun, 30 Nov 2008 14:16:04 UTC, moroney@world.std.spaamtrap.com 
> (Michael Moroney) wrote:
> 
>> =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>> 
>> >Richard B. Gilbert wrote:
>> 
>> >>                                                         A six bit 
>> >> code is sufficient to give you the alphabet, the decimal digits, and 
>> >> common punctuation with a few characters left over.
>> 
>> > > It's not clear to me that there is any point in packing six characters
>> > > into a "REAL*4".
>> 
>> >There are not room for 6 codes of 6 bit in 4 byte either.
>> 
>> >That only gives 5.33 bit per character.
>> 
>> RAD50 gives a character set of 40 characters (50 octal).  That's the 
>> letters A-Z uppercase, digits 0-9, space, two other punctuation characters
>> and one code which I think was never defined.  I believe this is how PDP-11
>> operating systems stored file names (a 6.3 name with an implicit period
>> could be stored as 3 words/6 bytes).
> 
> I said there'd be a pedant along in a minute! Arne is being the pedant -
> saying that it's not ASCII without a full character set...
> 
> Yes, I know that RT-11 and DOS/BATCH (who remembers DOS/BATCH?) stored 
> filenames in RAD50. And I think MACRO-11 stored symbols like that.

I still have my DOS/BATCH handbook.  It's from my first major paid
programming assignment which was to add RK07 drive support to DOS/BATCH.
It was actually a pretty neat little OS.


George Cook
WVNET

Arne Vajh�j wrote:

> Richard B. Gilbert wrote:
(snip)

>  > It's not clear to me that there is any point in packing six characters
>  > into a "REAL*4".

> There are not room for 6 codes of 6 bit in 4 byte either.

> That only gives 5.33 bit per character.

REAL*4 on the PDP-10 (FORTRAN-10) is 36 bits, and will hold six
SIXBIT characters, or five ASCII characters.

-- glen

Bob Eager skrev:
> On Sun, 30 Nov 2008 14:16:04 UTC, moroney@world.std.spaamtrap.com 
> (Michael Moroney) wrote:
> 
>> =?ISO-8859-1?Q?Arne_Vajh=F8j?= <arne@vajhoej.dk> writes:
>>
>>> Richard B. Gilbert wrote:
>>>>                                                         A six bit 
>>>> code is sufficient to give you the alphabet, the decimal digits, and 
>>>> common punctuation with a few characters left over.
>>>> It's not clear to me that there is any point in packing six characters
>>>> into a "REAL*4".
>>> There are not room for 6 codes of 6 bit in 4 byte either.
>>> That only gives 5.33 bit per character.
>> RAD50 gives a character set of 40 characters (50 octal).  That's the 
>> letters A-Z uppercase, digits 0-9, space, two other punctuation characters
>> and one code which I think was never defined.  I believe this is how PDP-11
>> operating systems stored file names (a 6.3 name with an implicit period
>> could be stored as 3 words/6 bytes).
> 
> I said there'd be a pedant along in a minute! Arne is being the pedant -
> saying that it's not ASCII without a full character set...

Actually, it's not even being a pedant. It's just plain silly to say that 
RADIX50 is ASCII, or anywhere close to it.
Compare with EBCDIC. That's not ASCII either. But it contains the same letters. 
As does R50. So, what defines ASCII? Actually, it's the interpretation of 7-bit 
values in a specific way that defines it as ASCII. Clearly, R50 have a different 
interpretation if you present the same seven bits, so it is in no way related to 
ASCII.
The fact that you have functions that can convert between ASCII and R50 should 
tell you all you need. Just as you can have functions that convert between ASCII 
and EBCDIC (as an example).

(Now, the pedant would point out that you can't view a 7-bit value from a R50 
point of view, since R50 deals with 16-bit values.)

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

In article <iPSdnQmedoe2763UnZ2dnUVZ_hmdnZ2d@giganews.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> My knowledge of ADA is almost non-existent!  The people I've talked with 
>   who do use ADA say that you CAN do almost anything; but you may have 
> to provide the compiler with an extensive explanation of what you are 
> trying to do.  This is as it should be.  A program that uses the same 
> address to store a float and a long int is a disaster waiting to happen.
> The original may work just fine but when it's modified. . . .

   I'm not familiar with the current Ada standard.  But if I have two 32
   bit signed integers I think the language should recognise that, no
   matter how many layers of user-defined typing I pile on top of it.
   Ada 86 did not.
   
   And I found that as soon as I needed to pass an array as an argument, I 
   had to define a type.  Which meant I coudn't just stick to the
   predefined types where they were suitable, and ended up having to
   tell the compiler all too often that yes, I really was just dealling
   with 32 bit signed integers.

   Mind you, my own ideas of what should be allowed are a lot closer to
   Ada 86 than they are to any version of C.  But I couldn't see the
   advantage to not being able pass an array of a predefined type.

In article <176uZD2KcidF-pn2-gfKy1RdgUebf@rikki.tavi.co.uk>, "Bob Eager" <rde42@spamcop.net> writes:
> 
> I think the origin of this is simply that internally, that's how they 
> work. All the instructions are broken down into RISC equivalents, as 
> that makes lots of things (pipe scheduling for one) much easier.

   Like the ALUs in the VAX 9000, but at a much lower price?  8-)

In article <6pdhvdF7g80lU2@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> Rhetorical question, right?  Running VMS means working with a whole
> different animal.  A more reasonable question would be, "Why would
> anyone want to run Linux on a VAX when it's just a poor stepchild
> to Unix and there are several excelent versions of Unix availble?" :-)

   Back when VAXen were cost competitive with other CPUs, it made sense
   to buy a VAX to run UNIX.  I knew a guy who learned to program on an
   11/750 running ULTRIX.  Lots of folks bought VAXen and put BSD UNIX
   on them.  BSD was arguably the most advanced UNIX for quite some
   time.

   Back when VAX was the only platform that would run VMS, it made a lot
   of sense to buy a VAX to run VMS.  But when UNIX on RISC came out it
   no longer made a lot of sense to buy a VAX to run UNIX.

   Long since Alpha first shipped it doesn't make a lot of sense to buy
   a VAX to run VMS.  Except for folks having significant hardware
   dependencies (I know several), it doens't make a lot of sense to buy
   a VAX for anything.

   But I'll keep on in my hobbyist cluster, just because I like using
   Macro-32 as a native language for some things.  Like teaching my kids
   assembler and having the full-screen mode for the debugger.

In article <001d9ecd$0$12337$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> 
> So why not make it available to even more platforms ? If its macro
> substitution is second to none, why not make others benefit from it ?

   There are a few little bugs in Macro-32's macro capability and lots
   of other langauges with good macro capabilities.  Try BLISS, for
   instance.

In article <6pdujdF7jt18U1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 
> Not possible?  I really expected someone to recognize RAD50 (aka RADIX-50)
> when I posted this.  :-)

   But you said ASCII.  The RAD50 character set is a subset of the ASCII
   character set, which is why it works.

   Of course, all PDP-10 programmers know how to put 5 (7-bit) ASCII 
   characters in a (36 bit) word, and the last release of the Fortran 
   compilers would allocate a full word if they saw REAL*4.

In article <0021061e$0$6670$c3e8da3@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> Imagine if Macro-32 were ported to OS-X.
> 
> Mr VAXman would be *really* happy.
> 
> And in the end, isn't it the goal of VMS engineering to try to make Mr
> VAXman happy because when he is happy, it means that all other customers
> are happy ?

   I don't think his kernel mode code would work on OS-X no matter what
   language it was written in.

   But if the Free-VMS folks ever completed thier BLISS compiler,
   someone might port that to OS-X.  You still couldn't port a lot of
   kernel mode code, but you could write it in the same language.
   

Tim E. Sneddon vaguely mentioned on 30-11-2008 16:51:

[snip]

> So does the internal jacketing done by TIE when going from the
> VAX or Alpha to Itanium environments and back the other way.

And another one from personal experience: I used to code against the 
Message Router DDS (Distributed Directory Services) interface way back 
when I was employed by Digital. It turned out that the published 
interface only worked with stack-oriented parameter passing languages, 
and for my own favourite programming language, Fortran, with its static 
parameter lists, we had to write a "DDS_CALL" jacket routine in Macro.

/Wilm

On Nov 28, 6:21=A0pm, Arne Vajh=F8j <a...@vajhoej.dk> wrote:
> Glen Herrmannsfeldt wrote:
> > NeilRieckwrote:
> >> I don't want to start a flame war but both Intel and AMD call their
> >> popular products RISC machines which happen to be able to run CISC
> >> code. This claim was probably engineered by sales folk because I never
> >> think of the descendants of Pentium4 as pure RISC architectures.
>
> > I believe AMD started, and Intel continued, the idea of having
> > the processor internally convert the CISC instruction stream
> > to RISCops and pass them through to the RISC part of the processor.
>
> > I don't know if any will let you write RISCop code directly, though.
>
> > It is much easier to do out-of-order execution at the RISCop level.
>
> Sure.
>
> But that is not the exposed instruction set.
>
> It is more like a specific way of implementing microcode.
>
> Arne

You have hit it right on the head. Intel's marketing people were
claiming that IA-32 (at least starting with Netburst) was RISC because
once those CISC instructions were decoded into microcode, it was
possible that some instructions could be executed in parallel and
maybe even out of order.

Now any rational person from the technicial side of the street knows
that RISC architectures have "large register sets available to the
programmer" as well as simple (usually single operand) instructions.
When ever I see someone using SIMD instructions like MMX or MMX2 I
know that the architecture can't possibly be RISC.

Neil

billg999@cs.uofs.edu (Bill Gunshannon) writes:

> In article <493175dd$0$90262$14726298@news.sunsite.dk>,
> 	Arne Vajh�j <arne@vajhoej.dk> writes:
>> Bill Gunshannon wrote:
>>> In article <176uZD2KcidF-pn2-rfsGVdt9vN3v@rikki.tavi.co.uk>,
>>> 	"Bob Eager" <rde42@spamcop.net> writes:
>>>> On Sat, 29 Nov 2008 14:36:09 UTC, Arne Vajhj <arne@vajhoej.dk> wrote:
>>>>
>>>>> Bill Gunshannon wrote:
>>>>>> In article <ggqcj2$ken$1@aioe.org>,
>>>>>> 	Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>>>>> Arne Vajhj wrote:
>>>>>>>
>>>>>>>> C Kermit is from around 1989-1990. I believe that it
>>>>>>>> took a few years until C-Kermit was stable enough to replace
>>>>>>>> the old VMS Kermit.
>>>>>>> Unix C kermit is older than that.  For other than unix,
>>>>>>> that might be about right.
>>>>>>>
>>>>>> The BLISS version worked just fine as far as I was concerned.
>>>>> The Bliss version was rock solid.
>>>>>
>>>>> But if I remember correctly, then the C version had
>>>>> better performance (due to ability to use larger
>>>>> buffers or something like that).
>>>> And sliding windows....allowing overlap between send and acknowledge.
>>> 
>>> Too bad there was no one to just add those features to the Bliss
>>> version.  Hmmmm...  Might be fun to try.  Especially for someone
>>> like me who's only experience with Bliss is knowing it's reputation.
>> 
>> FDC probably wanted to standardize on C Kermit on all/many platforms
>> (with a few OS specific modules) to lower the burden of
>> maintenance.

> Having provided platforms for compiling and maintenance of some Kermit
> versions as well as having maintained a few myself, I kknow Frank well
> enough that I would bet he would put up a newer version if someone went
> to the trouble of making one.  I have turned in binaries for versions
> of Kermit for machines not able to run C-Kermit, like the PDP-11.

In fact, when I was getting our 2065 up and running, Frank not only was excited
about fixing a bug in Tops-10 Kermit, but got the original author involved as
well.  In 2006.

And the result went into the appropriate distribution directory at Columbia.

So if you feel like tackling Kermit-32 to learn BLISS, I say "Go for it!"

-- 
Rich Alderson                  "You get what anybody gets. You get a lifetime."
news@alderson.users.panix.com                           --Death, of the Endless

In article <8lqnDTaJMYrA@eisner.encompasserve.org>,
	koehler@eisner.nospam.encompasserve.org (Bob Koehler) writes:
> In article <6pdujdF7jt18U1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>> 
>> Not possible?  I really expected someone to recognize RAD50 (aka RADIX-50)
>> when I posted this.  :-)
> 
>    But you said ASCII.  The RAD50 character set is a subset of the ASCII
>    character set, which is why it works.
> 
>    Of course, all PDP-10 programmers know how to put 5 (7-bit) ASCII 
>    characters in a (36 bit) word, and the last release of the Fortran 
>    compilers would allocate a full word if they saw REAL*4.
> 

Read what I posted again.  It came right out of my RT-11 Pocket Guide.
DEC sure seemed to think it was converting ASCII to REAL*4.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999@cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   

Johnny Billquist wrote:
(snip)

> The big point of having the PC as a general register is that you don't 
> need special opcodes for the instructions when you want to address 
> things PC-relative. It's just a normal addressing mode, with a general 
> register.
> It makes a lot of things easier. But sure, you can accomplish the same 
> thing without that feature. But it makes life more difficult.

Well, you don't need special opcodes but just addressing mode bits.

Then the question is, how to code those those bits efficiently.

They can be coded as register numbers even if PC isn't a
general register.  I believe that for VAX that not all addressing
modes using PC as an index register are valid, so it isn't
completely general.  Also, for VAX it would have been about
as easy to specify it using the address mode nybble, which
would allow for one or two more user registers.

-- glen

Bob Koehler skrev:
> In article <6pdujdF7jt18U1@mid.individual.net>, billg999@cs.uofs.edu (Bill Gunshannon) writes:
>> Not possible?  I really expected someone to recognize RAD50 (aka RADIX-50)
>> when I posted this.  :-)
> 
>    But you said ASCII.  The RAD50 character set is a subset of the ASCII
>    character set, which is why it works.

Hey! RAD50 is just as much a subset of EBCDIC. Try to prove me wrong. :-)

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Glen Herrmannsfeldt skrev:
> Johnny Billquist wrote:
> (snip)
> 
>> The big point of having the PC as a general register is that you don't 
>> need special opcodes for the instructions when you want to address 
>> things PC-relative. It's just a normal addressing mode, with a general 
>> register.
>> It makes a lot of things easier. But sure, you can accomplish the same 
>> thing without that feature. But it makes life more difficult.
> 
> Well, you don't need special opcodes but just addressing mode bits.
> 
> Then the question is, how to code those those bits efficiently.
> 
> They can be coded as register numbers even if PC isn't a
> general register.  I believe that for VAX that not all addressing
> modes using PC as an index register are valid, so it isn't
> completely general.  Also, for VAX it would have been about
> as easy to specify it using the address mode nybble, which
> would allow for one or two more user registers.

The point is, there are no special address mode patterns. Using the PC is no 
different from any other register, and the same address modes applies to the PC, 
just as to any other register.
The only thing you need to reserve is one register. So you have one less really 
general register.
It's about making it general and simple to read and understand.

Not having the PC as a general register makes a lot of things more difficult, 
but as I said before, it's not a showstopper. You can accomplish the same thing 
in other ways. It's just less intuitive and more headaches.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Johnny Billquist wrote:
(snip)

> Not having the PC as a general register makes a lot of things more 
> difficult, but as I said before, it's not a showstopper. You can 
> accomplish the same thing in other ways. It's just less intuitive and 
> more headaches.

On VAX, only half (X'8' through X'F') of the addressing modes
are available for the PC, anyway.

The real question, though, is does the PC need to be one of the
2**N registers available.  You can still give the PC the appropriate
address modes even if it is the 17th register, with appropriate
use of the bits.  Even if it is the 16th register, people
and compiler code generators will consider it different.

-- glen

In article <gh898e$4gu$1@aioe.org>, Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>Johnny Billquist wrote:
>(snip)
>
>> Not having the PC as a general register makes a lot of things more 
>> difficult, but as I said before, it's not a showstopper. You can 
>> accomplish the same thing in other ways. It's just less intuitive and 
>> more headaches.
>
>On VAX, only half (X'8' through X'F') of the addressing modes
>are available for the PC, anyway.

	MOVL	(PC)+,R0
	MOVL	(R0),[R1]
	CLRL	R0

If modes other than the defined Program Counter modes were permitted, which
instruction above would execute next?  It might have made for some interest-
ing hacking but, generally speaking, the results would often be very *VERY*
unpredictable.

Glen Herrmannsfeldt skrev:
> Johnny Billquist wrote:
> (snip)
> 
>> Not having the PC as a general register makes a lot of things more 
>> difficult, but as I said before, it's not a showstopper. You can 
>> accomplish the same thing in other ways. It's just less intuitive and 
>> more headaches.
> 
> On VAX, only half (X'8' through X'F') of the addressing modes
> are available for the PC, anyway.
> 
> The real question, though, is does the PC need to be one of the
> 2**N registers available.  You can still give the PC the appropriate
> address modes even if it is the 17th register, with appropriate
> use of the bits.  Even if it is the 16th register, people
> and compiler code generators will consider it different.

As I've said a number of times now - no, it don't have to be, but it makes 
things more troublesome when it isn't. :-)

Of course people and compilers will regard and treat the register differently, 
but the point is that the instructions don't.
If you remove the PC from the general registers, then instructions also need to 
treat it different.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

VAXman- @SendSpamHere.ORG skrev:
> In article <gh898e$4gu$1@aioe.org>, Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>> Johnny Billquist wrote:
>> (snip)
>>
>>> Not having the PC as a general register makes a lot of things more 
>>> difficult, but as I said before, it's not a showstopper. You can 
>>> accomplish the same thing in other ways. It's just less intuitive and 
>>> more headaches.
>> On VAX, only half (X'8' through X'F') of the addressing modes
>> are available for the PC, anyway.
> 
> 	MOVL	(PC)+,R0
> 	MOVL	(R0),[R1]
> 	CLRL	R0
> 
> If modes other than the defined Program Counter modes were permitted, which
> instruction above would execute next?  It might have made for some interest-
> ing hacking but, generally speaking, the results would often be very *VERY*
> unpredictable.

I don't understand the question.

	MOVL	(PC)+,R0

is a perfectly legal addressing with the PC. In fact, the above just happens to 
be what gets coded for an immediate mode argument. The next word in this case 
would be the literal.
Your example and question above is a little tricky, because we need to figure 
out how much is absorbed as the next longword. Unless my memory fails me:

	MOVL	(R0),[R1]

will take 3 bytes (or did indexing cause some extra byte on the argument as 
well...).
So possibly, the opcode of CLRL would also be a part of the immediate mode 
argument moved to R0, would could leave the R0 as the next instruction to 
execute, which of course is something else as an opcode.
Or if MOVL (R0),[R1] actually will take four bytes, then CLRL R0 is the next 
instruction to execute, while before that, R0 held the instruction sequence for 
the MOVL (R0),[R1]

This wasn't so popular to do on the VAX, since the instruction length is so 
variable, but on a PDP-11 this isn't that uncommon to actually find (well, maybe 
not every day, but it occasionally did happen).

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Johnny Billquist wrote:
(snip)

> I don't understand the question.

>     MOVL    (PC)+,R0

> is a perfectly legal addressing with the PC. In fact, the above just 
> happens to be what gets coded for an immediate mode argument. The next 
> word in this case would be the literal.

Address mode nybbles 0 through 7 are illegal for PC.  Well, 0-3
are literal, so there is no register.  Indexed is reserved
address mode fault.  Register, register deferred, and autodecrement
are unpredictable.

No  MOVL -(PC),-(PC)

allowed for VAX.

Modes 8 through F are marked as program counter addressing
and all have different assembler forms.

-- glen

In article <ghas8m$kau$1@Tempo.Update.UU.SE>, Johnny Billquist <bqt@update.uu.se> writes:
>VAXman- @SendSpamHere.ORG skrev:
>> In article <gh898e$4gu$1@aioe.org>, Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>> Johnny Billquist wrote:
>>> (snip)
>>>
>>>> Not having the PC as a general register makes a lot of things more 
>>>> difficult, but as I said before, it's not a showstopper. You can 
>>>> accomplish the same thing in other ways. It's just less intuitive and 
>>>> more headaches.
>>> On VAX, only half (X'8' through X'F') of the addressing modes
>>> are available for the PC, anyway.
>> 
>> 	MOVL	(PC)+,R0
>> 	MOVL	(R0),[R1]
>> 	CLRL	R0
>> 
>> If modes other than the defined Program Counter modes were permitted, which
>> instruction above would execute next?  It might have made for some interest-
>> ing hacking but, generally speaking, the results would often be very *VERY*
>> unpredictable.
>
>I don't understand the question.
>
>	MOVL	(PC)+,R0
>
>is a perfectly legal addressing with the PC. In fact, the above just happens to 

Well, the instruction would not assemble.

%MACRO-E-ILLREGHERE, This register may not be used here


>be what gets coded for an immediate mode argument. The next word in this case 
>would be the literal.
>Your example and question above is a little tricky, because we need to figure 
>out how much is absorbed as the next longword. Unless my memory fails me:
>
>	MOVL	(R0),[R1]

Oops...that was supposed to read MOVL    (R0),(R1)


>will take 3 bytes (or did indexing cause some extra byte on the argument as 
>well...).

Yes, the 8F is absolute mode.  I was trying to infer that *IF* the (PC)+ 
was a legal addressing mode would anyone know what would be executed as
the next instruction?  A simple case in my example (sorry about the [R1]
confusion) but toss in something else as the next instruction and there's
quite a crapshoot.


>So possibly, the opcode of CLRL would also be a part of the immediate mode 
>argument moved to R0, would could leave the R0 as the next instruction to 
>execute, which of course is something else as an opcode.
>Or if MOVL (R0),[R1] actually will take four bytes, then CLRL R0 is the next 
>instruction to execute, while before that, R0 held the instruction sequence for 
>the MOVL (R0),[R1]
>
>This wasn't so popular to do on the VAX, since the instruction length is so 
>variable, but on a PDP-11 this isn't that uncommon to actually find (well, maybe 
>not every day, but it occasionally did happen).

BINGO!  The variable instruction length!  This is why I believe it was NOT
made a permissible addressing mode with the PC.  Alpha has nice longword
instructions but on VAX?  One byte? Two bytes? Seven bytes? Twenty bytes?

Glen Herrmannsfeldt skrev:
> Johnny Billquist wrote:
> (snip)
> 
>> I don't understand the question.
> 
>>     MOVL    (PC)+,R0
> 
>> is a perfectly legal addressing with the PC. In fact, the above just 
>> happens to be what gets coded for an immediate mode argument. The next 
>> word in this case would be the literal.
> 
> Address mode nybbles 0 through 7 are illegal for PC.  Well, 0-3
> are literal, so there is no register.  Indexed is reserved
> address mode fault.  Register, register deferred, and autodecrement
> are unpredictable.
> 
> No  MOVL -(PC),-(PC)
> 
> allowed for VAX.
> 
> Modes 8 through F are marked as program counter addressing
> and all have different assembler forms.

My memory must be rotten... :-)

So, how did you code MOVL #4711,R0 then?
On a PDP-11, this would most definitely be coded as (disregardning the L here):

	MOV	(PC)+,R0
	4711

My befuddled brain believed the VAX did it the same way, but apparantly my brain 
is wrong. I know, I should grab the processor handbook and start reading, but I 
don't have the time at the moment, and maybe someone else can tell me then.

More stuff using the PC on a PDP11, by the way:

	MOV	#4711,4712

would be coded as

	MOV	(PC)+,n(PC)
	4711
	4712

and

	MOV	#4711,@4712

would be coded as

	MOV	(PC)+,@(PC)
	4711
	4712

and

	MOV	#4711,@#4712

as

	MOV	(PC)+,@(PC)+
	4711
	4712

heck, MACRO-11 even allows

	MOV	#4711,#4712

which is coded as (you might expect it)

	MOV	(PC)+,(PC)+
	4711
	4712

not very meaningful perhaps, since it just means that you'll overwrite the 4712 
with 4711, but it's perfectly valid to write it.

But the above is one of the really beatiful things about the PDP-11. The PC is a 
general register, just as any other. Some things might not be very meaningful, 
nor wise to do with the PC, but the instruction set don't have a problem with it 
on a technical level. (Ok, there are a pair of special details regarding R6 and 
R7, which might not be immediately obvious, but those make sense, even if they 
make the instruction set slightly tilted).

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

VAXman- @SendSpamHere.ORG skrev:
> In article <ghas8m$kau$1@Tempo.Update.UU.SE>, Johnny Billquist <bqt@update.uu.se> writes:
>> VAXman- @SendSpamHere.ORG skrev:
>>> In article <gh898e$4gu$1@aioe.org>, Glen Herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>>>> Johnny Billquist wrote:
>>>> (snip)
>>>>
>>>>> Not having the PC as a general register makes a lot of things more 
>>>>> difficult, but as I said before, it's not a showstopper. You can 
>>>>> accomplish the same thing in other ways. It's just less intuitive and 
>>>>> more headaches.
>>>> On VAX, only half (X'8' through X'F') of the addressing modes
>>>> are available for the PC, anyway.
>>> 	MOVL	(PC)+,R0
>>> 	MOVL	(R0),[R1]
>>> 	CLRL	R0
>>>
>>> If modes other than the defined Program Counter modes were permitted, which
>>> instruction above would execute next?  It might have made for some interest-
>>> ing hacking but, generally speaking, the results would often be very *VERY*
>>> unpredictable.
>> I don't understand the question.
>>
>> 	MOVL	(PC)+,R0
>>
>> is a perfectly legal addressing with the PC. In fact, the above just happens to 
> 
> Well, the instruction would not assemble.
> 
> %MACRO-E-ILLREGHERE, This register may not be used here

Wow. My memory have a parity error. :-)

>> be what gets coded for an immediate mode argument. The next word in this case 
>> would be the literal.
>> Your example and question above is a little tricky, because we need to figure 
>> out how much is absorbed as the next longword. Unless my memory fails me:
>>
>> 	MOVL	(R0),[R1]
> 
> Oops...that was supposed to read MOVL    (R0),(R1)

Ok. Makes it easier for me. Then it's definitely 3 bytes. :-)

>> will take 3 bytes (or did indexing cause some extra byte on the argument as 
>> well...).
> 
> Yes, the 8F is absolute mode.  I was trying to infer that *IF* the (PC)+ 
> was a legal addressing mode would anyone know what would be executed as
> the next instruction?  A simple case in my example (sorry about the [R1]
> confusion) but toss in something else as the next instruction and there's
> quite a crapshoot.

Well, there is no way you can expect to prevent if someone want to shoot himself 
in the foot, especially not if he writes in assembler...

>> So possibly, the opcode of CLRL would also be a part of the immediate mode 
>> argument moved to R0, would could leave the R0 as the next instruction to 
>> execute, which of course is something else as an opcode.
>> Or if MOVL (R0),[R1] actually will take four bytes, then CLRL R0 is the next 
>> instruction to execute, while before that, R0 held the instruction sequence for 
>> the MOVL (R0),[R1]
>>
>> This wasn't so popular to do on the VAX, since the instruction length is so 
>> variable, but on a PDP-11 this isn't that uncommon to actually find (well, maybe 
>> not every day, but it occasionally did happen).
> 
> BINGO!  The variable instruction length!  This is why I believe it was NOT
> made a permissible addressing mode with the PC.  Alpha has nice longword
> instructions but on VAX?  One byte? Two bytes? Seven bytes? Twenty bytes?

When misused, you can always mess up. You might just as well complain about the 
branch and jump instructions, which can jump right down in the middle of an 
instruction, since they are byte addresses.

The point being (atleast it was in my befuddled mind) that you don't normally 
write the code that way yourself, but instead let the assembler do it for you.

So, you write

	MOVL	#4711,R0

and the assembler codes it as

	MOVL	(PC)+,R0
	.LONG	4711

which will work out just fine. Correct length of the next argument, and PC will 
afterwards point to the next instruction to execute. Just as you might have 
expected.

Hey. I just gave up and grabbed the VAX processor handbook.

What are you people talking about? The PC in the VAX isn't any different than on 
the PDP-11. It's perfectly fine to use the PC almost anywhere where you use any 
other register. The only place it isn't allowed according to the processor 
handbook is as an index register. However, addressing modes 5-7 are defined as 
"unpredictable results" if the PC is used. No surprise there. :-)

If the assembler complain about it if you write

	MOVL	(PC)+,R0
	.LONG	4711

then it's just a stupid assembler. This actually *is* how immediate mode 
arguments are coded on the VAX (unless we're talking about small immediate mode 
arguments). So, if you write

	MOVL	#4711,R0

the above snippet is actually what the assembler will produce.

My memory wasn't bad after all. You people are trying to confuse me!

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Glen Herrmannsfeldt skrev:
> Johnny Billquist wrote:
> (snip)
> 
>> I don't understand the question.
> 
>>     MOVL    (PC)+,R0
> 
>> is a perfectly legal addressing with the PC. In fact, the above just 
>> happens to be what gets coded for an immediate mode argument. The next 
>> word in this case would be the literal.
> 
> Address mode nybbles 0 through 7 are illegal for PC.  Well, 0-3
> are literal, so there is no register.  Indexed is reserved
> address mode fault.  Register, register deferred, and autodecrement
> are unpredictable.
> 
> No  MOVL -(PC),-(PC)
> 
> allowed for VAX.
> 
> Modes 8 through F are marked as program counter addressing
> and all have different assembler forms.

And addressing mode 8 is:

	(Rn)+

guess what... ;-)

And while -(Rn) is addressing mode 7, the processor will deal with the fact that 
you use the PC there. It's just that the results are "undefined", which isn't 
that surprising, considering the variable length instructions on the VAX. Where 
you end up, and what is done next really is a crap shoot. So it's not something 
you'd do on a VAX. But (Rn)+ definitely is. The fact that the assembler have an 
alternate syntax which utilize those addressing modes when using the PC don't 
make them any different from the machine point of view.

A little sad that they don't approve of register mode with the PC though. Not 
surprising perhaps, since it's not as useful to read out the PC on the VAX, 
compared to a PDP-11, but anyway. I wonder (even suspect) that a
	MOVL	R0,PC
should cause a JUMP anyway, but there might be strangeness connected to this, 
such as perhaps PC being autoincremented after the MOVL have been executed, or 
other funny stuff...
Processor handbook just says "unpredictable". Atleast my version do. :-)

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Johnny Billquist <bqt@update.uu.se> writes:

>A little sad that they don't approve of register mode with the PC though. Not 
>surprising perhaps, since it's not as useful to read out the PC on the VAX, 
>compared to a PDP-11, but anyway. I wonder (even suspect) that a
>	MOVL	R0,PC
>should cause a JUMP anyway, but there might be strangeness connected to this, 
>such as perhaps PC being autoincremented after the MOVL have been executed, or 
>other funny stuff...
>Processor handbook just says "unpredictable". Atleast my version do. :-)

Back when I learned PDP-11 assembler and "got" how much the PC was just 
another register in so many ways, I wondered why they even bothered having
a separate JMP instruction.  Best that I could figure was that the syntax
was not consistent.  A JMP (R1) was equivalent in effect to MOV R1,R7, not
MOV (R1),R7.

Michael Moroney wrote:
(snip)

> Back when I learned PDP-11 assembler and "got" how much the PC was just 
> another register in so many ways, I wondered why they even bothered having
> a separate JMP instruction.  Best that I could figure was that the syntax
> was not consistent.  A JMP (R1) was equivalent in effect to MOV R1,R7, not
> MOV (R1),R7.

Considering the usefulness of conditional load, a conditional relative
jump is the same as a conditional load of indexed PC.

-- glen

On Mon, 8 Dec 2008 20:47:49 UTC, Glen Herrmannsfeldt 
<gah@ugcs.caltech.edu> wrote:

> Michael Moroney wrote:
> (snip)
> 
> > Back when I learned PDP-11 assembler and "got" how much the PC was just 
> > another register in so many ways, I wondered why they even bothered having
> > a separate JMP instruction.  Best that I could figure was that the syntax
> > was not consistent.  A JMP (R1) was equivalent in effect to MOV R1,R7, not
> > MOV (R1),R7.
> 
> Considering the usefulness of conditional load, a conditional relative
> jump is the same as a conditional load of indexed PC.

Conditional load is probably more useful than the JUMP instruction on 
the PDP-10...

-- 
Bob Eager

Michael Moroney skrev:
> Johnny Billquist <bqt@update.uu.se> writes:
> 
>> A little sad that they don't approve of register mode with the PC though. Not 
>> surprising perhaps, since it's not as useful to read out the PC on the VAX, 
>> compared to a PDP-11, but anyway. I wonder (even suspect) that a
>> 	MOVL	R0,PC
>> should cause a JUMP anyway, but there might be strangeness connected to this, 
>> such as perhaps PC being autoincremented after the MOVL have been executed, or 
>> other funny stuff...
>> Processor handbook just says "unpredictable". Atleast my version do. :-)
> 
> Back when I learned PDP-11 assembler and "got" how much the PC was just 
> another register in so many ways, I wondered why they even bothered having
> a separate JMP instruction.  Best that I could figure was that the syntax
> was not consistent.  A JMP (R1) was equivalent in effect to MOV R1,R7, not
> MOV (R1),R7.

I wondered about that for a while as well, until I realized one important 
difference. JMP don't affect the condition codes. That can be important sometimes...

Besides, JMP is probably faster. :-)

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Michael Moroney skrev:
> Johnny Billquist <bqt@update.uu.se> writes:
> 
>> A little sad that they don't approve of register mode with the PC though. Not 
>> surprising perhaps, since it's not as useful to read out the PC on the VAX, 
>> compared to a PDP-11, but anyway. I wonder (even suspect) that a
>> 	MOVL	R0,PC
>> should cause a JUMP anyway, but there might be strangeness connected to this, 
>> such as perhaps PC being autoincremented after the MOVL have been executed, or 
>> other funny stuff...
>> Processor handbook just says "unpredictable". Atleast my version do. :-)
> 
> Back when I learned PDP-11 assembler and "got" how much the PC was just 
> another register in so many ways, I wondered why they even bothered having
> a separate JMP instruction.  Best that I could figure was that the syntax
> was not consistent.  A JMP (R1) was equivalent in effect to MOV R1,R7, not
> MOV (R1),R7.

One "cool" thing, which I learned from BLISS-11, by the way.

Let's assume you have a small integer in R0, and you want to jump to different 
routines based on that value (let's say it's 0 to 3, for this example):

	ASL	R0	; Multiply value by 2
	ADD	R0,PC	; Dispatch
	BR	10$	; If value was 0
	BR	20$	; If value was 1
	BR	30$	; If value was 2
;
; Fall through here if value is 3
;

I was pretty impressed that BLISS-11 generated that kind of code. Another was 
like this:

TAB:	.WORD	DST1-BRP
	.WORD	DST2-BRP
	.WORD	DST3-BRP
	.WORD	DST4-BRP


..
..
..

	ASL	R0
	ADD	TAB(R0),PC
BRP:

..
..
..

DST1:		; Code
..
..
..

and so on...

Makes code PIC, while efficient. :-)

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Glen Herrmannsfeldt skrev:
> Michael Moroney wrote:
> (snip)
> 
>> Back when I learned PDP-11 assembler and "got" how much the PC was 
>> just another register in so many ways, I wondered why they even 
>> bothered having
>> a separate JMP instruction.  Best that I could figure was that the syntax
>> was not consistent.  A JMP (R1) was equivalent in effect to MOV R1,R7, 
>> not
>> MOV (R1),R7.
> 
> Considering the usefulness of conditional load, a conditional relative
> jump is the same as a conditional load of indexed PC.

Not sure I followed the logic here. Conditional loads and conditional relative 
jumps are all very nice, but none are available on a PDP-11, or a VAX, as far as 
I know.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Bob Eager skrev:
> On Mon, 8 Dec 2008 20:47:49 UTC, Glen Herrmannsfeldt 
> <gah@ugcs.caltech.edu> wrote:
> 
>> Michael Moroney wrote:
>> (snip)
>>
>>> Back when I learned PDP-11 assembler and "got" how much the PC was just 
>>> another register in so many ways, I wondered why they even bothered having
>>> a separate JMP instruction.  Best that I could figure was that the syntax
>>> was not consistent.  A JMP (R1) was equivalent in effect to MOV R1,R7, not
>>> MOV (R1),R7.
>> Considering the usefulness of conditional load, a conditional relative
>> jump is the same as a conditional load of indexed PC.
> 
> Conditional load is probably more useful than the JUMP instruction on 
> the PDP-10...

Considering that the JUMP instruction on a PDP-10 is a NOP, yes... :-)

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

On Tue, 9 Dec 2008 10:47:44 UTC, Johnny Billquist <bqt@update.uu.se> 
wrote:

> Bob Eager skrev:
> > On Mon, 8 Dec 2008 20:47:49 UTC, Glen Herrmannsfeldt 
> > <gah@ugcs.caltech.edu> wrote:
> > 
> >> Michael Moroney wrote:
> >> (snip)
> >>
> >>> Back when I learned PDP-11 assembler and "got" how much the PC was just 
> >>> another register in so many ways, I wondered why they even bothered having
> >>> a separate JMP instruction.  Best that I could figure was that the syntax
> >>> was not consistent.  A JMP (R1) was equivalent in effect to MOV R1,R7, not
> >>> MOV (R1),R7.
> >> Considering the usefulness of conditional load, a conditional relative
> >> jump is the same as a conditional load of indexed PC.
> > 
> > Conditional load is probably more useful than the JUMP instruction on 
> > the PDP-10...
> 
> Considering that the JUMP instruction on a PDP-10 is a NOP, yes... :-)

Exactly. A really nice, totally orthogonal instruction set, though!

-- 
Bob Eager

Johnny Billquist <bqt@update.uu.se> writes:

>Michael Moroney skrev:
>> 
>> Back when I learned PDP-11 assembler and "got" how much the PC was just 
>> another register in so many ways, I wondered why they even bothered having
>> a separate JMP instruction.  Best that I could figure was that the syntax
>> was not consistent.  A JMP (R1) was equivalent in effect to MOV R1,R7, not
>> MOV (R1),R7.

>I wondered about that for a while as well, until I realized one important 
>difference. JMP don't affect the condition codes. That can be important sometimes...

You know, I think I once made the same realization but had forgotten about 
it by the time I made my reply.  It is a very important difference!

>Besides, JMP is probably faster. :-)

Probably.

In article <176uZD2KcidF-pn2-9qVdXhjTdFfm@rikki.tavi.co.uk>, "Bob Eager" <rde42@spamcop.net> writes:
> 
> Exactly. A really nice, totally orthogonal instruction set, though!
> 

   Orthogonal?  When did they take out the extra instructions?