stg

[muta...@gmail.com]

Something I noticed on the mainframe is that
the transition from 32 bit to 64 bit simply
involved changing instructions like st (store)
to stg (store grand).

You may as well have an assembler
option to do that automatically.

So you can just code st and tell the
assembler whether you want 32 bit integers
or 64 bit integers or 1024 bit integers.

You could probably do the same thing
with 16 bit integers except you run
out of memory if you want to
do much of anything so segmentation
needs to be added to the mix.

So you may only need one compiler,
assembler and linker and os and c
library, all doing s370 and you have a
completely portable suite for
eternity.

[Joe Monk]

On Friday, November 25, 2022 at 7:13:55 PM UTC-6, muta...@gmail.com wrote:
> Something I noticed on the mainframe is that
> the transition from 32 bit to 64 bit simply
> involved changing instructions like st (store)
> to stg (store grand).
>

Wrong.

Different instructions, different formats.

ST - RX-a
STG - RXY-a

Joe

[muta...@gmail.com]

The assembler works simply by
adding a G though, which is all I need.

Ok, so the person writing the assembler
may potentially need to change opcodes.

But you could keep the opcodes the same if
you were happy to go pure 64 bit.

Not an actual zarch.

[Joe Monk]

> The assembler works simply by
> adding a G though, which is all I need.
>

No it doesnt.

Joe

[Joe Monk]

ST is a 31-bit instruction of the form R1,X2,B2,D2 and D2 is 12 bits.

STG is a 48-bit instruction of the form R1,X2,B2,DL2,DH2 and DL2+DH2 is 20 bits.

Joe

[muta...@gmail.com]

Not sure if we're talking cross purposes.

If you see st label, that can be changed to stg label.

It's that simple for the c compiler.

The c compiler will need to make that
target 8 bytes instead of 4 bytes though.

[muta...@gmail.com]

You can restrict yourself to just using 12 of those 20 available bits
so that the c compiler generates identical
assembler, basically.

[Joe Monk]

> You can restrict yourself to just using 12 of those 20 available bits
> so that the c compiler generates identical
> assembler, basically.

But you cant restrict the assembler to just using 12 of those 20 bits! Nor the hardware.

Joe

[muta...@gmail.com]

You can restrict the assembler (not IBM's
version obviously), but that's irrelevant because
the c compiler simply won't generate an instruction
that would use more than 12 bits.

The hardware will never be exposed because
of that too.

[Joe Monk]

> You can restrict the assembler (not IBM's
> version obviously), but that's irrelevant because
> the c compiler simply won't generate an instruction
> that would use more than 12 bits.
>
> The hardware will never be exposed because
> of that too.

The instant you use STG you are using 20-bits. Its how the instruction is defined ... it uses 20 bits.

Joe

[muta...@gmail.com]

That depends on your definition.

My code will run on hardware that only
supports 12 bits. Ie ignores the upper 8
bits or throws an error if they are non-zero.

[anti...@math.uni.wroc.pl]

I am not sure what you want to do. If you want
your 32-bit code to run on 64-bit machine but
still be 32-bit, then on most 64-bit machines that
is reasonably easy. OTOH if you want to have
64-bit addresses, and use 64-bit data then things
are a bit more complicated. First, size of your
data increases. I you simply double size of everything,
then you need to multiply all addresses and offsets
by 2. You can not do this at assembler level, because
assembler does not know which number is an address
and which is simply data, so that must be done in
compiler.

In real life adjustment of size will be more complicated,
some types keep their size, some double. This is not
a problem for a compiler, but must be implemented.

Concerning 370: since data may be bigger also offsets
may be bigger. It may happen that offset which in
32-bit mode fits ino 12 bits will grow so that it no
longer fits int 12-bits. That will force you to do
some workarounds. Easiest one is to use newer
instructions with bigger offsets (this could be done
by assembler). But whatever you decide compiler must
know which offsets can be done by single instruction
and which need extra code to work around machine
limitation.

All this logic could be put in single compiler, you
just need a few parameters describing modes of your
machine. And something like command line argument
telling compiler what it should do: 32-bit mode or
64-bit mode. As long as you do not care about quality
of generated code this could be done in very simple
compiler. But one which is better organised than
SubC. In fact, rather simple compiler could generate
code for multiple machine architectures: original lcc
did this.

--
Waldek Hebisch

[muta...@gmail.com]

On Sunday, November 27, 2022 at 7:23:21 AM UTC+8, anti...@math.uni.wroc.pl wrote:

> Concerning 370: since data may be bigger also offsets
> may be bigger. It may happen that offset which in
> 32-bit mode fits ino 12 bits will grow so that it no
> longer fits int 12-bits. That will force you to do
> some workarounds. Easiest one is to use newer
> instructions with bigger offsets (this could be done
> by assembler). But whatever you decide compiler must
> know which offsets can be done by single instruction
> and which need extra code to work around machine
> limitation.

Yes, the page table things will need to be more frequent
as the bit size increases.

> All this logic could be put in single compiler, you
> just need a few parameters describing modes of your
> machine. And something like command line argument
> telling compiler what it should do: 32-bit mode or
> 64-bit mode. As long as you do not care about quality
> of generated code this could be done in very simple
> compiler.

Yeah, that's what I'm after.

A parameter given to the compiler specifying the size.
No change to the assembler required - just get it to
generate the same opcodes, but now they have a
64-bit meaning instead of 32-bit. 80386 already has
this notion with the x'66' and x'67' if you want the
old style. Maybe something like that could be added
to S/370 as an alternative 64-bit move.

(note that I haven't moved to 64-bit yet anywhere that
I code)

Standardize on S/370. Standardize on a.out. Standardize
on C90.

And you have a viable machine no matter how many bits
they end up with in the future.

People can still spend effort optimizing various things,
writing in assembler for specific machines, using RISC,
changing their mind back and forth.

But the S/370 (now with 9999999 bits and counting) is
always there for you.

And then maybe throw in a segmented version of S/370,
and make it 16-bit and 8-bit.

Or maybe 8086 is better suited for segmentation, so let
S/370 inspire 8086 to be 999999 bit with just a compiler
option.

Just trying to get things clear - I'm not saying any of the
above is correct.

BFN. Paul.

[anti...@math.uni.wroc.pl]

Well, S/370 is not good choice, it is limited to 24-bit
addressing. You probably think that 360 was first
"nice" architecture on the market. But original 360
was supposed to run with 4k of memory (I am not sure if
any was actually shipped with such small memory) and that
probably motivated some unfortunate "savings" like packing
extra info in top 8-bits in system registers and some
instructions. Anyway, S370XE (that is with 31-bit
addressing) is probably minimal reasonable thing for
long time use. But it appeared only 1978 and at that
time it was possible to do better architecture. ARM
is nicer and simpler to implement.

> And you have a viable machine no matter how many bits
> they end up with in the future.
>
> People can still spend effort optimizing various things,
> writing in assembler for specific machines, using RISC,
> changing their mind back and forth.
>
> But the S/370 (now with 9999999 bits and counting) is
> always there for you.
>
> And then maybe throw in a segmented version of S/370,
> and make it 16-bit and 8-bit.

There was 16-bit 360: 360/20, it was limited to 64k of core
(or maybe only 32k). Once you have more memory there
is really no sense to use 16-bit: on small machines 360/370
instructions were interpreted by real processor and interpreter
for 32-bit instructions is only marginally more complex
than interpreter for 16-bit instructions. And interpreted
32-bit instructions are faster than segmented 16-bit ones.
To be more precise: both 360/20 and 360/30 stored official
360 registers in core memory. Processing only 16 bits
could give some saving due to smaller number of accesses to
core. But once you have segments in the mix there is no
saving: you need to handle 32-bits anyway and interpreter
gets more complex and slower.

> Or maybe 8086 is better suited for segmentation, so let
> S/370 inspire 8086 to be 999999 bit with just a compiler
> option.

Once you have compiler, there is really no need to insist
that architectures are very similar. I can do:

../../../../usr/bin/sdcc -mstm8 --opt-code-size -c -V pff.c

and it compiles FAT filesystem for STM8 (8-bit CISC). Or

/mnt/m1/pom/usr/bin/avr-gcc -Os -mmcu=atmega328 -c pff.c

to compile for Atmega328 (8-bit RISC). Or

/mnt/m1/pom/usr/bin/msp430-elf-gcc -Os -c pff.c

to compile for MSP430 (16-bit RISC). Or

/mnt/m1/pom/usr/bin/arm-none-eabi-gcc -Os -mthumb -mcpu=cortex-m0 -c pff.c

to compile for Cortex-M0 (very simplified version of ARM). Or

/mnt/m1/pom/usr/bin/arm-none-eabi-gcc -Os -mthumb -mcpu=cortex-m3 -c pff.c

to compile for Cortex-M3 (simpilfied ARM, but much richer than M0). Or
for several others. Of course, gcc is complex compiler but this
complexity is mainly to get good speed and small size of object code.
If you are satisfied with slower and bigger code, then much simpler
compiler is enough.

--
Waldek Hebisch

[Joe Monk]

> There was 16-bit 360: 360/20, it was limited to 64k of core
> (or maybe only 32k). Once you have more memory there
> is really no sense to use 16-bit: on small machines 360/370
> instructions were interpreted by real processor and interpreter
> for 32-bit instructions is only marginally more complex
> than interpreter for 16-bit instructions. And interpreted
> 32-bit instructions are faster than segmented 16-bit ones.
> To be more precise: both 360/20 and 360/30 stored official
> 360 registers in core memory. Processing only 16 bits
> could give some saving due to smaller number of accesses to
> core. But once you have segments in the mix there is no
> saving: you need to handle 32-bits anyway and interpreter
> gets more complex and slower.

The 360/20 only had 8 registers (8-F) compared with the larger models which had 16 registers (0-F). Yes they were 16 bit registers, and they were NOT stored in RAM.

The 360/20 was limited to 16K of RAM.

Otherwise it was pretty much a full blown 360. You still to this day can take a program from a 360/20 and run it on the latest z/arch processors.

"Direct Addressing: Direct addressing is used when the high-order bit in the B-field of an instruction is zero.
When the direct addressing method is employed, the low-order 14 bits of the combined B- and D-fields are used to refer directly to byte locations in main storage. The 12 binary bits in the D-field allow an address specification of up to 4095. To address additional (optional) storage, the adjacent two bits in the low-order pOSition of the B-field are used, allowing address specification of up to 16383."

http://www.bitsavers.org/pdf/ibm/360/functional_characteristics/A26-5847-3_360-20_funChar_Apr67.pdf

Joe

[muta...@gmail.com]

On Monday, November 28, 2022 at 11:59:14 PM UTC+8, anti...@math.uni.wroc.pl wrote:

> > Standardize on S/370. Standardize on a.out. Standardize
> > on C90.

> Well, S/370 is not good choice, it is limited to 24-bit
> addressing.

The instruction set has no such limit. You can write
a program and it can run on an AM32 or even an
AM64 or AM-infinity machine (as well as AM24).

> instructions. Anyway, S370XE (that is with 31-bit

XA

> Once you have compiler, there is really no need to insist
> that architectures are very similar.

The reason I insist that is so that the assembler and
linker don't need to be rewritten.

Ritchie created a language that, as far as I can tell, was
designed to last for eternity.

I want to write an eternal OS and eternal toolchain in that eternal language.

At a minimum I want to support flat 32, 64, 128, 256-bit
registers.

Ideally I would support 16:16, 32:32, 64:64, 128:128
segmentation too.

But I don't know which architecture to settle on.

I guess I could provide multiple assemblers to give
more eternal OS/toolchains.

BFN. Paul.

[Joe Monk]

> Ritchie created a language that, as far as I can tell, was
> designed to last for eternity.

Which is why it has already been superseded...

https://dlang.org
https://www.rust-lang.org
https://go.dev

Joe

[Scott Lurndal]

I think you're getting ahead of yourself. Augmented, perhaps.

Superceded, not yet, and probably not for a decade or so...

[Joe Monk]

> Superceded, not yet, and probably not for a decade or so...

It has already begun...

https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-windows/

https://www.i-programmer.info/news/98-languages/15538-rust-gets-into-the-kernel.html

https://hub.packtpub.com/rust-is-the-future-of-systems-programming-c-is-the-new-assembly-intel-principal-engineer-josh-triplett/

Joe

[Scott Lurndal]

Joe Monk <joem...@gmail.com> writes:
>
>> Superceded, not yet, and probably not for a decade or so...
>
>It has already begun...

That's what they said in 1989 about C++. C is still one of
the most widely used languages. Even for new projects.

[Joe Monk]

> That's what they said in 1989 about C++. C is still one of
> the most widely used languages. Even for new projects.

Except unlike '89, there are big names behind this push...

Torvalds and Russinovich just to name a couple...

https://www.theregister.com/2022/09/28/is_it_time_to_retire_c/

https://twitter.com/markrussinovich/status/1571995117233504257

Joe

[Scott Lurndal]

Joe Monk <joem...@gmail.com> writes:
>> That's what they said in 1989 about C++. C is still one of
>> the most widely used languages. Even for new projects.
>
>Except unlike '89, there are big names behind this push...
>
>Torvalds and Russinovich just to name a couple...
>
>https://www.theregister.com/2022/09/28/is_it_time_to_retire_c/

I read this when it was published. It's an opinion piece by
the microsoft CTO. I don't agree with his premise or conclusions.

During my over forty years of C and C++ programming, other languages
have come and gone. C and C++ programmers will still be desired forty
years from now. As will COBOL programmers. And likely Rust and Fortran.

I'm less than sanguine about go, haskell and others.

[Scott Lurndal]

Although the fact that SAS[*] and SPSS are still being sold after fifty
years, indicates that niche software can exist for a long time.

[*] Not to be confused with SAP.

[muta...@gmail.com]

Which future architecture do you see on the horizon,
even long term horizon, that allows those languages
to run, but not C?

I know of past architectures that C can't really run on,
at least in any sensible form, but not future ones.

I'm not familiar with those other languages to know if
they are capable of running on those older architectures,
which gives you the confidence that they, but not C,
are more likely to run on the future ones.

BFN. Paul.

[anti...@math.uni.wroc.pl]

muta...@gmail.com <muta...@gmail.com> wrote:
> On Monday, November 28, 2022 at 11:59:14 PM UTC+8, anti...@math.uni.wroc.pl wrote:
>
> > > Standardize on S/370. Standardize on a.out. Standardize
> > > on C90.
>
> > Well, S/370 is not good choice, it is limited to 24-bit
> > addressing.
>
> The instruction set has no such limit. You can write
> a program and it can run on an AM32 or even an
> AM64 or AM-infinity machine (as well as AM24).

Well, instruction set is defined is specific way. You can
try to reinterpret it in different way, but in the process
you have to throw away a few intructions that do not fit.
And you miss several useful intructions, some added in later
editions, some which appear in other architectures.

> > instructions. Anyway, S370XE (that is with 31-bit
>
> XA
>
> > Once you have compiler, there is really no need to insist
> > that architectures are very similar.
>
> The reason I insist that is so that the assembler and
> linker don't need to be rewritten.

Assemblers are really not complicated. Main part is
(possibly largish) table describing instructions and
their formats. There rest is normally quite similar
unless machine has some special quirks like segmentation
or similar.

Normal linker really does not care about architecture. Output
from compilers has slots with associated formulas (relocations).
What matter is what kind of relocations are needed. And
once you handle S370 you basically met most difficulties
that can appear anywhere: fields of varying size and need
to put address constants in memory. Again, if machine
has some quirks, then you may need special code in the
linker.

And actually, OS and its object formats have more impact on
linker than architecure. In virtual memory OS without
shared libraries you can link any program to use fixed
addresses. If you want to load programs at different
virtual adress (like in DOS), you need to apply relocations
during loading which make things more complicated. Shared
libraries lead to extra problems. Modern Linux uses
ELF format for shared libraries. IIUC essentially the
same thing was done by TSS/67 folks. But they run
into troubles. AFAICS one problem was that IBM360 required
more more relocations than modern machines. Another was
that TSS/67 was rather big for its time and took large
part of machine resources to itself. In effect, smaller
part of machine was available to user programs leading
to lower efficiency than competition.

> Ritchie created a language that, as far as I can tell, was
> designed to last for eternity.

Well, most (all???) high level languages were designed to
last for eternity. Certainly this was case with Fortran
and Cobol. But as we learn more about programming we
want more features from programming languages. In particular,
Fortran, Cobol, C when designed were viewed as high level
languages. In modern times they are viewed as just one
step above assembly with other languages like Python
viewed as really high level ones.

One research OS was originally written in Haskel, proven
correct and then hand translated to C again with proof
that translation is doing the same thing as original.
The main point of this excercise was to get mathematical
proof of correctness of OS. But as a byproduct it
indicates that Haskel is viable language to write an OS.
More precisely, authors have written OS using Haskel constructs
that could be translated to efficient machine code. When
compiled by normal Haskel compiler OS run rather slowly,
so they translated it to C. But AFAICS translation could
be done in mechanical way, so special purpose Haskel
compiler in pinciple could generate fast machine code.

> I want to write an eternal OS and eternal toolchain in that eternal language.
>
> At a minimum I want to support flat 32, 64, 128, 256-bit
> registers.
>
> Ideally I would support 16:16, 32:32, 64:64, 128:128
> segmentation too.
>
> But I don't know which architecture to settle on.
>
> I guess I could provide multiple assemblers to give
> more eternal OS/toolchains.
>
> BFN. Paul.

--
Waldek Hebisch

[Joe Monk]

> Which future architecture do you see on the horizon,
> even long term horizon, that allows those languages
> to run, but not C?
>

Rust is the future.

C is the new COBOL.

Joe

[anti...@math.uni.wroc.pl]

This is not really question of "not running", if you really
want you will find some way to run C programs (maybe using
soemthing like Bochs). Rather, in programming there are
3 desirable properties: runtime efficiency (speed and memory use),
programming convenience and safety/correctnes. And they
point in different directions. C was and still is reasonably good
at runtime efficiency. C from the start was rather bad in
safety/correctnes part: it is easy to write C code with
errors and langage offers little help in finding them.
Concerning convenience, among languages of comparable
efficiency C was about average.

Now, once you drop efficiency requirements a bit it is possible
to significantly increase safety/correctnes. Namely, compiler
inserted checks, in particular array bounds checks, can catch
many errors. In the past bounds checks were frequently
dismissed as inefficient. But with modern optimizing
compiler bounds checks typically add less than 10% to runtime,
which means that optimized program with bounds checks
will typically run faster than unoptimized one without
bounds checks. However, C is rather special. Unlike Pascal,
Ada, Fortran or Cobol it is almost impossible to automatically
insert bounds checks into C program without large loss
of efficiency (of order 3-4 times slower and bigger).
This is because in C arrays are almost immediately converted
to pointers and all what compiler sees are pointers. And
compiler does not know if a pointer points to single item
or an array (and if it points to array does not know
how what are array bounds).

In C++ one can use C arrays, with trouble as above or one
can use C++ vector classes which allow efficient bounds
checking.

Concerning convenience, there is large gain in conveniece
and also safety/correctness from using automatic memory
management. Usually this takes form of so called garbage
collection and several languages offer this. Old time
wisdom was that garbage collected language is not good
for writing an OS. But even this is debatable. For example,
VM370 is written in assembler. But is has "memory
management" subsystem. I looked a bit at this subsystem
and AFAICS this is a garbage collector for various OS
data structures. So, allocation is manual and there
are some manual deallocations but there is also
garbage collection. In principle making this more
automatic by using garbage collected language could
lead to easier programming and smaller number of errors.
And whatever difficulties garbage collection bring to
an OS are already there.

There are also another trends, using partial automation.
Here C++ has "smart pointers" and Rust introduced so
called "borrow checker". Rust promises that compiler
can check correcness of all deallocation. It will
take some time to see if this works as promised, but
even if this works only partially, it is better to have
partial checks than none at all.

Coming back to C, it is possible that there will be tools
which bring some of those developements to C. There is
historical precedent: in early C history there was
program called "lint" that performed extra checks
(IIUC in spirit of Pascal) on C programs. Classic
"lint" seem to be redundant in modern C, because
standard is more tight now and compilers issue many
warnings for legal but suspicous programs. But there
is room for new tools. Time will tell if C world manages
to adapt. AFAICS for some kind of code C++ is much
more convenient than plain C. Currently programming
small micros seem to be C stronghold. But C++ is very
strong competitor there, one can have programs where
object code is say 2k (so really small), C and C++
produce essentially the same size and speed, but C++
is more convenient to write. In fact, due to convenice
C++ programmer is likely to have more efficiency
improvments in the program than C programmer, so
in real life C++ may be more efficient.

Let me mentions extra thing related to OS. Namely,
C adoped linking model from linkers used around 1970.
Currently, major OS-es use C lining model and
effectively C conventions are forced on other
languages. But it seems that one could have better
linking model, more adaped to other langages. In
traditional model symbol have one meaning and only
thing that matter is name and how it is realted to
memory adresses. But in higher level languages
symbols have type, and types could be passed to the
linker. So linker could refuse linking symbols with
mismatched types or (for C++) could allow multiple
meanings, one for each type. That could simplify
linking from other languages to C++. OTOH typed linker
could break some C programs. I am not sure if it would
break legal C programs (IIUC in the past there was
belief that it would break some). Typed linker
would break assumption present in GNU configure,
namly that it could link with wrong types to
determine presence of functions in libraries.

--
Waldek Hebisch