> I tire of hearing about people calculating Pi to billions of digits.
> What good does that do?

Recreation? Challenge? Benchmark? (And I thought that _I_ was a
whiner.)

My quick search on this new Inter-Web thing for "pi many digits"
found (among many other things):

https://cloud.google.com/blog/products/compute/calculating-100-trillion-digits-of-pi-on-google-cloud

(No surprise, perhaps, that that was first in the Google search
results.)

I seem to have found a pi-calculating program in 1999, and run it on
a few of my systems then. Comparing the output for a million digits
(give or take) on a VAXstation 2000 (VMS V5.5-2) and a more recent run
on a Mac Pro (Late 2013)/VMware (VMS E9.2):

v87 $ diff 1048576_DIGITS_OF_PI_B_WEAK 1048576_DIGITS_OF_PI_B_V87
************
File V87$DKA0:[SMS.PI]1048576_DIGITS_OF_PI_B_WEAK.;1
24123 Total Execution time: 113515.44 Seconds
24124
******
File V87$DKA0:[SMS.PI]1048576_DIGITS_OF_PI_B_V87.;1
24123 Total Execution time: 11.38 Seconds
24124
************

Of course, the x86_64 results might suffer from the sub-optimal cross
(C) compiler.

> Looks correct but NASA doesn't use more than [...]

Same search, further down:

https://www.jpl.nasa.gov/edu/news/2016/3/16/how-many-decimals-of-pi-do-we-really-need/

In article <3f0c602f-2688-4945-a4f1-27aadad5aca5n@googlegroups.com>,
Steven Schweda <sms.antinode@gmail.com> wrote:
>> I tire of hearing about people calculating Pi to billions of digits.
>> What good does that do?
>
> Recreation? Challenge? Benchmark? (And I thought that _I_ was a
>whiner.)

Some people are waiting to find out if it repeats.

Some people want random values.

But it's a great integer benchmark.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

> Some people are waiting to find out if it repeats.

Given the centuries-old proof that it's irrational, that could be a
very long wait. (You don't even need transcendental for that.)

On Sun, 2023-03-19 at 12:09 +0000, Scott Dorsey wrote:
> Some people are waiting to find out if it repeats.

It never will. THat's the beauty about this number!
--
Tactical Nuclear Kittens

On 2023-03-17 17:01, Steven Schweda wrote:
>> Am I confused? [...]
>
> Perhaps.
>
>> [...] I was under the impression that pi comes from the
>> division of the diameter with the circumference of a circle.
>> No logarithmic or trigonometric anywhere near that...
>
> arccos( -1) = ?
>
> Trying to disconnect trig functions from circles and pi seems (to me)
> perverse and unproductive. Or does your Web search for:
> trigonometry "unit circle"
> find nothing?

Just because something gives pi does not mean it is the definition of pi.
I thought this was about the definition.

Johnny

On 2023-03-17 17:34, Scott Dorsey wrote:
> In article <tv1ver$9ls$1@news.misty.com>,
> Johnny Billquist <bqt@softjar.se> wrote:
>> On 2023-03-15 21:58, Arne Vajhøj wrote:
>>> Transcendental numbers are the real numbers that are
>>> not algebraic. All the "weird" numbers like e, pi,
>>> results from logarithmic or trigonometric functions (except
>>> for a a few selected inputs).
>>
>> Am I confused? I was under the impression that pi comes from the
>> division of the diameter with the circumference of a circle.
>
> It does but it ALSO is the sum of 4 - 4/3 + 4/5 - 4/7 + 4/9 - ....
>
> Or it's tan-1 of 0.
>
> It's everywhere you look. It's pretty creepy.

Right. Of course there are many ways of doing computations that will
give pi.

But I don't think it's that helpful to just show some method of how pi
can be computed. I think talking about the definition is what is more
interesting.

Otherwise we're talking about infinite series of sums. Which is just
approximations in reality, since you will never compute the final value
of an infinite series...

Johnny

In article <tv790f$np5$1@news.misty.com>,
Johnny Billquist <bqt@softjar.se> wrote:
>On 2023-03-17 17:01, Steven Schweda wrote:
>>> Am I confused? [...]
>>
>> Perhaps.
>>
>>> [...] I was under the impression that pi comes from the
>>> division of the diameter with the circumference of a circle.
>>> No logarithmic or trigonometric anywhere near that...
>>
>> arccos( -1) = ?
>>
>> Trying to disconnect trig functions from circles and pi seems (to me)
>> perverse and unproductive. Or does your Web search for:
>> trigonometry "unit circle"
>> find nothing?
>
>Just because something gives pi does not mean it is the definition of pi.
>I thought this was about the definition.

You were correct. The usual definiton of Pi is the ratio
of a circle's circumference to its diameter. Pi and e are
transcendental over the reals.

- Dan C.

> Otherwise we're talking about infinite series of sums. [...]

The usual definitions are:

Sequence: a set of numbers.

Series: the sum of the terms in a sequence.

> [...] you will never compute the final value of an infinite series...

Watch me. S = 1/2 + 1/4 + 1/8 + 1/16 + ... = 1

2 * S = 1 + S. Work it out.

> Advice on math and science found on comp.os.vms is generally
> unreliable, I claim.

Still my claim.

In article <330ad98a-f752-49f4-b1c0-5cd674487fa5n@googlegroups.com>,
Steven Schweda <sms.antinode@gmail.com> wrote:
>> Otherwise we're talking about infinite series of sums. [...]
>
> The usual definitions are:
>
> Sequence: a set of numbers.

Errm, hmm. This is insufficient. Order matters in a sequence,
and the elements of a sequence are enumerable. Plus, elements
can be repeated. One can define an isomorphism between a
sequence and, say, a subset of the naturals that would represent
each element as a tuple, with f: S -> N x S where F(s) = (s, k)
for k the index of s in the sequence, and with f': N x S -> S
being projection.

> Series: the sum of the terms in a sequence.
>
>
>> [...] you will never compute the final value of an infinite series...
>
> Watch me. S = 1/2 + 1/4 + 1/8 + 1/16 + ... = 1
>
> 2 * S = 1 + S. Work it out.

The basic idea here is correct; summing an infinite sequence has
some value if the series is convergent. The value of that
geometric series really is exactly 1, in the same way that
0.11111111... really is exactly 1/9.

Regardless, Johnny's original definiton of Pi was correct.

- Dan C.

Arne Vajhøj schrieb am Samstag, 18. März 2023 um 01:26:39 UTC+1:
> On 3/16/2023 5:05 AM, Andreas Gruhl wrote:
> > Arne Vajhøj schrieb am Donnerstag, 16. März 2023 um 01:47:31 UTC+1:
> >> On 3/10/2023 4:01 PM, Arne Vajhøj wrote:
> >>> Pre-release for comments:
> >>>
> >>> https://www.vajhoej.dk/arne/articles/vms64.html
> >>
> >> Updated to version 1.0 based on comments.
> > Small correction: PASCAL/USAGE=64BIT_TO_DESCR does NOT change the
> > compiler's treatment of pointers. Interpreting pointers as unsigned
> > values has to be provided by the programmer. The qualifier only
> > allows for P2 structures to be used as actual routine parameters via
> > descriptor, which otherwise would be flagged as a compile time
> > error.
> So it does not change the treatment of pointers.
>
> It disables a compiler check.
>
> Like allowing this to compile:
>
> procedure whatever(...; %STDESCR somearg; ...); external;
> ...
> (* z is in lower 2 GB of P2 space *)
> ...
> whatever(..., z, ...);
>
> ?
>
> Arne
That's correct.
'whatever' then has to take care of interpreting somearg as a descriptor and treating the pointer contained inside as unsigned.
We usually enable direct access to descriptors by using two different routine declarations, e.g.
[external(whatever_i)] procedure whatever(...; %STDESCR somearg; ...); external; (* official declaration *)
[global] procedure whatever_i(...; var somearg : dsc$type; ...); external; (* internal implementation, dsc$type from starlet *)
type ptr_string = [quad]^packed array[1..1000] of char;
var uns : unsigned64 ;
ptr : ptr_string; (* a 64 bit pointer *)
begin
uns:=somearg.dsc$a_pointer::unsigned; (* convert to 64 bits avoiding sign extension *)
ptr:=uns::ptr_string; (* convert to 64 bit pointer type *)
(* ptr can now be used to access the z argument without any further restrictions. *)
....
end;
This works for all z addresses between 0 and %XFFFFFFFF, which includes P0, P1 and the first 2 GB of P2
(if you encounter even larger addresses, only the lower 32 address bits will be correct - but sometimes this can help, too).
We use this heavily to extend the lifetime of our 32-bit routines into the 64 bit era without having to apply
changes to the calling programs.
And again: none of these programs misses the default behaviour of addresses above %7FFFFFFF to access system space.
This feature is almost useless for application programs. Whereas doubling the available address space into P2 is VERY useful.
Andreas

On 3/20/2023 5:37 AM, Andreas Gruhl wrote:
> Arne Vajhøj schrieb am Samstag, 18. März 2023 um 01:26:39 UTC+1:
>> On 3/16/2023 5:05 AM, Andreas Gruhl wrote:
>>> Arne Vajhøj schrieb am Donnerstag, 16. März 2023 um 01:47:31 UTC+1:
>>>> On 3/10/2023 4:01 PM, Arne Vajhøj wrote:
>>>>> Pre-release for comments:
>>>>>
>>>>> https://www.vajhoej.dk/arne/articles/vms64.html
>>>>
>>>> Updated to version 1.0 based on comments.
>>> Small correction: PASCAL/USAGE=64BIT_TO_DESCR does NOT change the
>>> compiler's treatment of pointers. Interpreting pointers as unsigned
>>> values has to be provided by the programmer. The qualifier only
>>> allows for P2 structures to be used as actual routine parameters via
>>> descriptor, which otherwise would be flagged as a compile time
>>> error.
>> So it does not change the treatment of pointers.
>>
>> It disables a compiler check.
>>
>> Like allowing this to compile:
>>
>> procedure whatever(...; %STDESCR somearg; ...); external;
>> ...
>> (* z is in lower 2 GB of P2 space *)
>> ...
>> whatever(..., z, ...);
>>
>> ?

> That's correct.

I have updated.

Arne

On Tuesday, March 21, 2023 at 11:34:04 AM UTC, Arne Vajhøj wrote:
> On 3/20/2023 5:37 AM, Andreas Gruhl wrote:
> > Arne Vajhøj schrieb am Samstag, 18. März 2023 um 01:26:39 UTC+1:
> >> On 3/16/2023 5:05 AM, Andreas Gruhl wrote:
> >>> Arne Vajhøj schrieb am Donnerstag, 16. März 2023 um 01:47:31 UTC+1:
> >>>> On 3/10/2023 4:01 PM, Arne Vajhøj wrote:
> >>>>> Pre-release for comments:
> >>>>>
> >>>>> https://www.vajhoej.dk/arne/articles/vms64.html
> >>>>
> >>>> Updated to version 1.0 based on comments.
> >>> Small correction: PASCAL/USAGE=64BIT_TO_DESCR does NOT change the
> >>> compiler's treatment of pointers. Interpreting pointers as unsigned
> >>> values has to be provided by the programmer. The qualifier only
> >>> allows for P2 structures to be used as actual routine parameters via
> >>> descriptor, which otherwise would be flagged as a compile time
> >>> error.
> >> So it does not change the treatment of pointers.
> >>
> >> It disables a compiler check.
> >>
> >> Like allowing this to compile:
> >>
> >> procedure whatever(...; %STDESCR somearg; ...); external;
> >> ...
> >> (* z is in lower 2 GB of P2 space *)
> >> ...
> >> whatever(..., z, ...);
> >>
> >> ?
> > That's correct.
>
> I have updated.
>
> Arne
On VMS E9.2-1 x86-64 all code by default is put into P2 by the linker but you can put /SEGMENT=CODE=P0 to stop that. I suspect this is going to cause some issues when porting. For kernel mode code the recommendation is to change from locking specific parts of the code into the working set to locking the whole image as this works on I64 and x86 VMS by calling LIB$LOCK_IMAGE.

On 3/22/2023 7:18 AM, Ian Miller wrote:
> On Tuesday, March 21, 2023 at 11:34:04 AM UTC, Arne Vajhøj wrote:
>> On 3/20/2023 5:37 AM, Andreas Gruhl wrote:
>>> Arne Vajhøj schrieb am Samstag, 18. März 2023 um 01:26:39 UTC+1:
>>>> On 3/16/2023 5:05 AM, Andreas Gruhl wrote:
>>>>> Arne Vajhøj schrieb am Donnerstag, 16. März 2023 um 01:47:31
>>>>> UTC+1:
>>>>>> On 3/10/2023 4:01 PM, Arne Vajhøj wrote:
>>>>>>> https://www.vajhoej.dk/arne/articles/vms64.html
>>>>>>
>>>>>> Updated to version 1.0 based on comments.
>>>>> Small correction: PASCAL/USAGE=64BIT_TO_DESCR does NOT change
>>>>> the compiler's treatment of pointers. Interpreting pointers
>>>>> as unsigned values has to be provided by the programmer. The
>>>>> qualifier only allows for P2 structures to be used as actual
>>>>> routine parameters via descriptor, which otherwise would be
>>>>> flagged as a compile time error.
>>>> So it does not change the treatment of pointers.
>>>>
>>>> It disables a compiler check.

>>> That's correct.
>>
>> I have updated.

> On VMS E9.2-1 x86-64 all code by default is put into P2 by the linker
> but you can put /SEGMENT=CODE=P0 to stop that. I suspect this is
> going to cause some issues when porting. For kernel mode code the
> recommendation is to change from locking specific parts of the code
> into the working set to locking the whole image as this works on I64
> and x86 VMS by calling LIB$LOCK_IMAGE.

So is a function pointer always 64 bit?

Arne

On Wednesday, March 22, 2023 at 2:50:17 PM UTC, Arne Vajhøj wrote:
> On 3/22/2023 7:18 AM, Ian Miller wrote:
> > On Tuesday, March 21, 2023 at 11:34:04 AM UTC, Arne Vajhøj wrote:
> >> On 3/20/2023 5:37 AM, Andreas Gruhl wrote:
> >>> Arne Vajhøj schrieb am Samstag, 18. März 2023 um 01:26:39 UTC+1:
> >>>> On 3/16/2023 5:05 AM, Andreas Gruhl wrote:
> >>>>> Arne Vajhøj schrieb am Donnerstag, 16. März 2023 um 01:47:31
> >>>>> UTC+1:
> >>>>>> On 3/10/2023 4:01 PM, Arne Vajhøj wrote:
> >>>>>>> https://www.vajhoej.dk/arne/articles/vms64.html
> >>>>>>
> >>>>>> Updated to version 1.0 based on comments.
> >>>>> Small correction: PASCAL/USAGE=64BIT_TO_DESCR does NOT change
> >>>>> the compiler's treatment of pointers. Interpreting pointers
> >>>>> as unsigned values has to be provided by the programmer. The
> >>>>> qualifier only allows for P2 structures to be used as actual
> >>>>> routine parameters via descriptor, which otherwise would be
> >>>>> flagged as a compile time error.
> >>>> So it does not change the treatment of pointers.
> >>>>
> >>>> It disables a compiler check.
> >>> That's correct.
> >>
> >> I have updated.
> > On VMS E9.2-1 x86-64 all code by default is put into P2 by the linker
> > but you can put /SEGMENT=CODE=P0 to stop that. I suspect this is
> > going to cause some issues when porting. For kernel mode code the
> > recommendation is to change from locking specific parts of the code
> > into the working set to locking the whole image as this works on I64
> > and x86 VMS by calling LIB$LOCK_IMAGE.
> So is a function pointer always 64 bit?
>
> Arne

from the release notes "The LINKER creates small stub routines in 32-bit P0 space to allow the address of a routine to be stored in a 32-bit variable."

On Wednesday, March 22, 2023 at 1:13:20 PM UTC-4, Ian Miller wrote:
> On Wednesday, March 22, 2023 at 2:50:17 PM UTC, Arne Vajhøj wrote:
> > On 3/22/2023 7:18 AM, Ian Miller wrote:
> > > On Tuesday, March 21, 2023 at 11:34:04 AM UTC, Arne Vajhøj wrote:
> > >> On 3/20/2023 5:37 AM, Andreas Gruhl wrote:
> > >>> Arne Vajhøj schrieb am Samstag, 18. März 2023 um 01:26:39 UTC+1:
> > >>>> On 3/16/2023 5:05 AM, Andreas Gruhl wrote:
> > >>>>> Arne Vajhøj schrieb am Donnerstag, 16. März 2023 um 01:47:31
> > >>>>> UTC+1:
> > >>>>>> On 3/10/2023 4:01 PM, Arne Vajhøj wrote:
> > >>>>>>> https://www.vajhoej.dk/arne/articles/vms64.html
> > >>>>>>
> > >>>>>> Updated to version 1.0 based on comments.
> > >>>>> Small correction: PASCAL/USAGE=64BIT_TO_DESCR does NOT change
> > >>>>> the compiler's treatment of pointers. Interpreting pointers
> > >>>>> as unsigned values has to be provided by the programmer. The
> > >>>>> qualifier only allows for P2 structures to be used as actual
> > >>>>> routine parameters via descriptor, which otherwise would be
> > >>>>> flagged as a compile time error.
> > >>>> So it does not change the treatment of pointers.
> > >>>>
> > >>>> It disables a compiler check.
> > >>> That's correct.
> > >>
> > >> I have updated.
> > > On VMS E9.2-1 x86-64 all code by default is put into P2 by the linker
> > > but you can put /SEGMENT=CODE=P0 to stop that. I suspect this is
> > > going to cause some issues when porting. For kernel mode code the
> > > recommendation is to change from locking specific parts of the code
> > > into the working set to locking the whole image as this works on I64
> > > and x86 VMS by calling LIB$LOCK_IMAGE.
> > So is a function pointer always 64 bit?
> >
> > Arne
> from the release notes "The LINKER creates small stub routines in 32-bit P0 space to allow the address of a routine to be stored in a 32-bit variable."

For the most part, few people have noticed that the code now resides in 64-bit space. The linker-created trampolines hide the details. The trampoline IS the routine's address. Shareable image symbol-vectors feel more like VAX these days since they also are an array of trampolines.

What I've seen more is VAX-era code (mostly Macro-32 and BLISS) that goes out of the way to place readonly data into the $CODE$ PSECT or mark $PLIT$/$LITERAL$/etc as EXE. On VAX, getting those literals near the code can result in byte or word-relative addressing modes which might save a few bytes. On Alpha or Itanium, having that data near the code didn't do anything (perhaps a little benefit for locality or reducing image segment counts?). On x86, marking those PSECTs as EXE moves that static data into 64-bit space as well. There are no "trampolines" to help so you can't take their 32-bit address for things like descriptors, item lists, etc. You get strange looking ACCVIOs from using just 32-bits of a larger than 32-bit address. Again, this is 99% a Macro-32 and BLISS technique to save a byte on VAX. Code written in C, C++, Fortran, etc. does the right thing by letting the compiler figure it out. And people who modify PSECT attributes in linker options files can shoot themselves in the foot (I just fixed one of those yesterday!)

And you can move code into P2 space on Itanium too but it isn't the default.. That linker has /SEGMENT=CODE=P2 if you want to try it (doesn't work well with C++ however).

The benefit of moving code out of P0 space is to free up more 32-bit heap, etc.

It has been this way with x86 since day-1. Our original design model was to put code in P2 space (and likewise more of the OS is now in S2 space)

John

On Wednesday, March 22, 2023 at 5:37:07 PM UTC, John Reagan wrote:
> On Wednesday, March 22, 2023 at 1:13:20 PM UTC-4, Ian Miller wrote:
> > On Wednesday, March 22, 2023 at 2:50:17 PM UTC, Arne Vajhøj wrote:
> > > On 3/22/2023 7:18 AM, Ian Miller wrote:
> > > > On Tuesday, March 21, 2023 at 11:34:04 AM UTC, Arne Vajhøj wrote:
> > > >> On 3/20/2023 5:37 AM, Andreas Gruhl wrote:
> > > >>> Arne Vajhøj schrieb am Samstag, 18. März 2023 um 01:26:39 UTC+1:
> > > >>>> On 3/16/2023 5:05 AM, Andreas Gruhl wrote:
> > > >>>>> Arne Vajhøj schrieb am Donnerstag, 16. März 2023 um 01:47:31
> > > >>>>> UTC+1:
> > > >>>>>> On 3/10/2023 4:01 PM, Arne Vajhøj wrote:
> > > >>>>>>> https://www.vajhoej.dk/arne/articles/vms64.html
> > > >>>>>>
> > > >>>>>> Updated to version 1.0 based on comments.
> > > >>>>> Small correction: PASCAL/USAGE=64BIT_TO_DESCR does NOT change
> > > >>>>> the compiler's treatment of pointers. Interpreting pointers
> > > >>>>> as unsigned values has to be provided by the programmer. The
> > > >>>>> qualifier only allows for P2 structures to be used as actual
> > > >>>>> routine parameters via descriptor, which otherwise would be
> > > >>>>> flagged as a compile time error.
> > > >>>> So it does not change the treatment of pointers.
> > > >>>>
> > > >>>> It disables a compiler check.
> > > >>> That's correct.
> > > >>
> > > >> I have updated.
> > > > On VMS E9.2-1 x86-64 all code by default is put into P2 by the linker
> > > > but you can put /SEGMENT=CODE=P0 to stop that. I suspect this is
> > > > going to cause some issues when porting. For kernel mode code the
> > > > recommendation is to change from locking specific parts of the code
> > > > into the working set to locking the whole image as this works on I64
> > > > and x86 VMS by calling LIB$LOCK_IMAGE.
> > > So is a function pointer always 64 bit?
> > >
> > > Arne
> > from the release notes "The LINKER creates small stub routines in 32-bit P0 space to allow the address of a routine to be stored in a 32-bit variable."
> For the most part, few people have noticed that the code now resides in 64-bit space. The linker-created trampolines hide the details. The trampoline IS the routine's address. Shareable image symbol-vectors feel more like VAX these days since they also are an array of trampolines.
>
> What I've seen more is VAX-era code (mostly Macro-32 and BLISS) that goes out of the way to place readonly data into the $CODE$ PSECT or mark $PLIT$/$LITERAL$/etc as EXE. On VAX, getting those literals near the code can result in byte or word-relative addressing modes which might save a few bytes. On Alpha or Itanium, having that data near the code didn't do anything (perhaps a little benefit for locality or reducing image segment counts?). On x86, marking those PSECTs as EXE moves that static data into 64-bit space as well. There are no "trampolines" to help so you can't take their 32-bit address for things like descriptors, item lists, etc. You get strange looking ACCVIOs from using just 32-bits of a larger than 32-bit address. Again, this is 99% a Macro-32 and BLISS technique to save a byte on VAX. Code written in C, C++, Fortran, etc. does the right thing by letting the compiler figure it out. And people who modify PSECT attributes in linker options files can shoot themselves in the foot (I just fixed one of those yesterday!)
>
> And you can move code into P2 space on Itanium too but it isn't the default. That linker has /SEGMENT=CODE=P2 if you want to try it (doesn't work well with C++ however).
>
> The benefit of moving code out of P0 space is to free up more 32-bit heap, etc.
>
> It has been this way with x86 since day-1. Our original design model was to put code in P2 space (and likewise more of the OS is now in S2 space)
>
> John

I've only noticed when porting some MACRO32 ;-)

On 3/22/2023 1:37 PM, John Reagan wrote:
> On Wednesday, March 22, 2023 at 1:13:20 PM UTC-4, Ian Miller wrote:
>> On Wednesday, March 22, 2023 at 2:50:17 PM UTC, Arne Vajhøj wrote:
>>> On 3/22/2023 7:18 AM, Ian Miller wrote:
>>>> On VMS E9.2-1 x86-64 all code by default is put into P2 by the
>>>> linker but you can put /SEGMENT=CODE=P0 to stop that.

>>> So is a function pointer always 64 bit?

>> from the release notes "The LINKER creates small stub routines in
>> 32-bit P0 space to allow the address of a routine to be stored in
>> a 32-bit variable."
VMS is VMS.

:-)

> For the most part, few people have noticed that the code now resides
> in 64-bit space. The linker-created trampolines hide the details.
> The trampoline IS the routine's address. Shareable image
> symbol-vectors feel more like VAX these days since they also are an
> array of trampolines.
>
> What I've seen more is VAX-era code (mostly Macro-32 and BLISS) that
> goes out of the way to place readonly data into the $CODE$ PSECT or
> mark $PLIT$/$LITERAL$/etc as EXE.

They have do something special.

$ type hw.mar
.title hw
.psect $CODE quad,pic,con,lcl,shr,exe,nowrt
hw: .asciz "Hello world!"
.entry gethw,^m<>
movab hw,r0
ret
.end
$ macro hw

hw: .asciz "Hello world!"
^ %AMAC-E-DATINCODE, data in code stream
at line number 3 in file DISK2:[ARNE]hw.mar;1

Of course they can do:

$ type hw2.mar
.title hw2
.psect $PDATA quad,pic,con,lcl,shr,noexe,nowrt
hw: .asciz "Hello world!"
.psect $CODE quad,pic,con,lcl,shr,exe,nowrt
.entry gethw,^m<>
movab hw,r0
ret
.end
$ macro hw2
$ type hw0.c
#include <stdio.h>

char *gethw();

int main(int argc, char *argv[])
{ printf("%s\n", gethw());
return 0;
} $ cc hw0
$ link/map hw0 + hw2 + sys$input/opt
psect_attr=$pdata,EXE
$ $ run hw0
Hello world!

which if I understand correct will fail on x86-64
default and on Itanium with eksplicit /SEGMENT=CODE=P2
because returning a P2 address in 32 bit just doesn't work.

Arne

On 3/25/2023 1:09 PM, Arne Vajhøj wrote:
>
>
> $ type hw.mar
>         .title  hw
>         .psect  $CODE quad,pic,con,lcl,shr,exe,nowrt
> hw:     .asciz  "Hello world!"
^^^^^^

>         .entry  gethw,^m<>
>         movab   hw,r0
>         ret
>         .end
> $ macro hw
>
> hw:     .asciz  "Hello world!"
> ^
> %AMAC-E-DATINCODE, data in code stream
> at line number 3 in file DISK2:[ARNE]hw.mar;1
>
> Of course they can do:
>
> $ type hw2.mar
>         .title  hw2
>         .psect  $PDATA quad,pic,con,lcl,shr,noexe,nowrt
> hw:     .asciz  "Hello world!"
^^^^^^

>         .psect  $CODE quad,pic,con,lcl,shr,exe,nowrt
>         .entry  gethw,^m<>
>         movab   hw,r0
>         ret
>         .end

I thought null terminated strings was a C thing and a bad idea? :-)

bill

On 3/25/2023 1:17 PM, bill wrote:
> On 3/25/2023 1:09 PM, Arne Vajhøj wrote:
>>
>>
>> $ type hw.mar
>> .title hw
>> .psect $CODE quad,pic,con,lcl,shr,exe,nowrt
>> hw: .asciz "Hello world!"
> ^^^^^^
>
>
>> .entry gethw,^m<>
>> movab hw,r0
>> ret
>> .end
>> $ macro hw
>>
>> hw: .asciz "Hello world!"
>> ^
>> %AMAC-E-DATINCODE, data in code stream
>> at line number 3 in file DISK2:[ARNE]hw.mar;1
>>
>> Of course they can do:
>>
>> $ type hw2.mar
>> .title hw2
>> .psect $PDATA quad,pic,con,lcl,shr,noexe,nowrt
>> hw: .asciz "Hello world!"
> ^^^^^^
>
>
>> .psect $CODE quad,pic,con,lcl,shr,exe,nowrt
>> .entry gethw,^m<>
>> movab hw,r0
>> ret
>> .end
>
> I thought null terminated strings was a C thing and a bad idea? :-)
>
> bill
>

There was ASCIZ before there was C. But still not advisable.

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

On 3/25/2023 1:30 PM, Dave Froble wrote:
> On 3/25/2023 1:17 PM, bill wrote:
>> On 3/25/2023 1:09 PM, Arne Vajhøj wrote:
>>>
>>>
>>> $ type hw.mar
>>>          .title  hw
>>>          .psect  $CODE quad,pic,con,lcl,shr,exe,nowrt
>>> hw:     .asciz  "Hello world!"
>>           ^^^^^^
>>
>>
>>>          .entry  gethw,^m<>
>>>          movab   hw,r0
>>>          ret
>>>          .end
>>> $ macro hw
>>>
>>> hw:     .asciz  "Hello world!"
>>> ^
>>> %AMAC-E-DATINCODE, data in code stream
>>> at line number 3 in file DISK2:[ARNE]hw.mar;1
>>>
>>> Of course they can do:
>>>
>>> $ type hw2.mar
>>>          .title  hw2
>>>          .psect  $PDATA quad,pic,con,lcl,shr,noexe,nowrt
>>> hw:     .asciz  "Hello world!"
>>           ^^^^^^
>>
>>
>>>          .psect  $CODE quad,pic,con,lcl,shr,exe,nowrt
>>>          .entry  gethw,^m<>
>>>          movab   hw,r0
>>>          ret
>>>          .end
>>
>> I thought null terminated strings was a C thing and a bad idea?  :-)
>>
>> bill
>>
>
> There was ASCIZ before there was C.  But still not advisable.
>

I knew there was. I just find it funny that everyone holds that
idea up as the very worst thing in C and yet, as you said, it was
the industry standard long before C came around. Had C done it
differently I am sure people would have bitched about abandoning
the current standard.

bill

On 3/25/2023 1:17 PM, bill wrote:
> On 3/25/2023 1:09 PM, Arne Vajhøj wrote:
>>
>>
>> $ type hw.mar
>>          .title  hw
>>          .psect  $CODE quad,pic,con,lcl,shr,exe,nowrt
>> hw:     .asciz  "Hello world!"
>           ^^^^^^
>
>>          .entry  gethw,^m<>
>>          movab   hw,r0
>>          ret
>>          .end
>> $ macro hw
>>
>> hw:     .asciz  "Hello world!"
>> ^
>> %AMAC-E-DATINCODE, data in code stream
>> at line number 3 in file DISK2:[ARNE]hw.mar;1
>>
>> Of course they can do:
>>
>> $ type hw2.mar
>>          .title  hw2
>>          .psect  $PDATA quad,pic,con,lcl,shr,noexe,nowrt
>> hw:     .asciz  "Hello world!"
>           ^^^^^^
>
>>          .psect  $CODE quad,pic,con,lcl,shr,exe,nowrt
>>          .entry  gethw,^m<>
>>          movab   hw,r0
>>          ret
>>          .end
>
> I thought null terminated strings was a C thing and a bad idea?  :-)

Well - it is being returned to a C program, so it made sense to me.

Arne

On 3/25/2023 2:04 PM, bill wrote:
> On 3/25/2023 1:30 PM, Dave Froble wrote:
>> On 3/25/2023 1:17 PM, bill wrote:
>>> I thought null terminated strings was a C thing and a bad idea?  :-)
>>
>> There was ASCIZ before there was C.  But still not advisable.
>
> I knew there was.  I just find it funny that everyone holds that
> idea up as the very worst thing in C

Probably not the worst thing. Just not particular good.

> and yet, as you said, it was
> the industry standard long before C came around.

Used/seen before yes. Industry standard I don't think so.

>   Had C done it
> differently I am sure people would have bitched about abandoning
> the current standard.

There are usually always people willing to complain about
anything.

But I do not remember anyone complaining about strings not
being null terminated char arrays in newer languages.

Arne

bill <bill.gunshannon@gmail.com> wrote:
>I knew there was. I just find it funny that everyone holds that
>idea up as the very worst thing in C and yet, as you said, it was
>the industry standard long before C came around. Had C done it
>differently I am sure people would have bitched about abandoning
>the current standard.

Quite possibly, but they would have had a lot fewer buffer overrun
vulnerabilities while doing so.

I am a big fan of C and I definitely think null-terminated strings
were a mistake. There are syntax issues in C that I don't like, but
there is nothing in the same order of magnitude as null terminated
strings.

But, at the time C was made, the notion that people would attempt to
deliberately cause software to malfunction seemed alien. It no longer
is, and as the world has changed the design decisions that seem appropriate
may have changed as well.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2023-03-25, Scott Dorsey <kludge@panix.com> wrote:
> bill <bill.gunshannon@gmail.com> wrote:
>>I knew there was. I just find it funny that everyone holds that
>>idea up as the very worst thing in C and yet, as you said, it was
>>the industry standard long before C came around. Had C done it
>>differently I am sure people would have bitched about abandoning
>>the current standard.
>
> Quite possibly, but they would have had a lot fewer buffer overrun
> vulnerabilities while doing so.
>
> I am a big fan of C and I definitely think null-terminated strings
> were a mistake. There are syntax issues in C that I don't like, but
> there is nothing in the same order of magnitude as null terminated
> strings.
>
> But, at the time C was made, the notion that people would attempt to
> deliberately cause software to malfunction seemed alien. It no longer
> is, and as the world has changed the design decisions that seem appropriate
> may have changed as well.

In this very different world, gets() was once considered to be an acceptable
function. :-)

In the more recent world, strncpy() is not always guaranteed to write
a terminating null. Absolutely no excuse for that one :-(, especially
given that it was supposed to be a fix for strcpy() (IIRC).

Other annoyances (apart from the null-terminated strings):

= for assignment, versus == for comparison. (At least it's not PHP however,
where you need to use === to get a sane comparison. :-))

enums are integers, not a type.

Functions are public unless marked as static. I would have preferred them
to be private by default with the need for a "public" keyword to make the
function visible to the linker.

signed characters are the default.

Simon.

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

On 3/27/2023 8:27 AM, Simon Clubley wrote:
> = for assignment, versus == for comparison. (At least it's not PHP however,
> where you need to use === to get a sane comparison. :-))

C == is not that great either.

$ type eq.c
#include <stdio.h>
#include <stdlib.h>

#define TEST(a, b) printf(#a " == " #b " : %d\n", a == b)

int main()
{ TEST(0, 0);
TEST(0, 1);
TEST(1, 0);
TEST(1, 1);
TEST(0, 0.0);
TEST(0, 1.0);
TEST(1, 0.0);
TEST(1, 1.0);
TEST(0, 0.1);
TEST(0, 1.1);
TEST(1, 0.1);
TEST(1, 1.1);
TEST(0, FALSE);
TEST(0, TRUE);
TEST(1, FALSE);
TEST(1, TRUE);
TEST(0, "ABC");
TEST(0, NULL);
TEST(1, "ABC");
TEST(1, NULL);
return 0;
} $ cc eq

TEST(1, "ABC");
.....^
%CC-W-CVTDIFTYPES, In this statement, "1" of type "int", is being
converted to "pointer to char".
at line number 26 in file DISK2:[ARNE]eq.c;1

TEST(1, NULL);
.....^
%CC-W-CVTDIFTYPES, In this statement, "1" of type "int", is being
converted to "pointer to void".
at line number 27 in file DISK2:[ARNE]eq.c;1
$ link eq
%LINK-W-WRNERS, compilation warnings
in module EQ file DISK2:[ARNE]eq.OBJ;2
$ run eq
0 == 0 : 1
0 == 1 : 0
1 == 0 : 0
1 == 1 : 1
0 == 0.0 : 1
0 == 1.0 : 0
1 == 0.0 : 0
1 == 1.0 : 1
0 == 0.1 : 0
0 == 1.1 : 0
1 == 0.1 : 0
1 == 1.1 : 0
0 == FALSE : 1
0 == TRUE : 0
1 == FALSE : 0
1 == TRUE : 1
0 == "ABC" : 0
0 == NULL : 1
1 == "ABC" : 0
1 == NULL : 0
$ type eq.php
<?php

function test($a, $b) {
echo "$a == $b : " . ($a == $b) . "\r\n";
}

test(0, 0);
test(0, 1);
test(1, 0);
test(1, 1);
test(0, 0.0);
test(0, 1.0);
test(1, 0.0);
test(1, 1.0);
test(0, 0.1);
test(0, 1.1);
test(1, 0.1);
test(1, 1.1);
test(0, FALSE);
test(0, TRUE);
test(1, FALSE);
test(1, TRUE);
test(0, "ABC");
test(0, NULL);
test(1, "ABC");
test(1, NULL);

?>
$ php eq.php
0 == 0 : 1
0 == 1 :
1 == 0 :
1 == 1 : 1
0 == 0 : 1
0 == 1 :
1 == 0 :
1 == 1 : 1
0 == 0.1 :
0 == 1.1 :
1 == 0.1 :
1 == 1.1 :
0 == : 1
0 == 1 :
1 == :
1 == 1 : 1
0 == ABC : 1
0 == : 1
1 == ABC :
1 == :
$ type eq2.php
<?php

function test($a, $b) {
echo "$a === $b : " . ($a === $b) . "\r\n";
}

test(0, 0);
test(0, 1);
test(1, 0);
test(1, 1);
test(0, 0.0);
test(0, 1.0);
test(1, 0.0);
test(1, 1.0);
test(0, 0.1);
test(0, 1.1);
test(1, 0.1);
test(1, 1.1);
test(0, FALSE);
test(0, TRUE);
test(1, FALSE);
test(1, TRUE);
test(0, "ABC");
test(0, NULL);
test(1, "ABC");
test(1, NULL);

?>
$ php eq2.php
0 === 0 : 1
0 === 1 :
1 === 0 :
1 === 1 : 1
0 === 0 :
0 === 1 :
1 === 0 :
1 === 1 :
0 === 0.1 :
0 === 1.1 :
1 === 0.1 :
1 === 1.1 :
0 === :
0 === 1 :
1 === :
1 === 1 :
0 === ABC :
0 === :
1 === ABC :
1 === :

Arne