In attempting writting a simple language, I had a thought of what language
is
to share. Because I saw many people are stuck in thinking C/C++ (or other
high level language) can be so abstract, unlimited 'high level' to mysterio usly
solve various human description of idea.

C and assembly are essentially the same, maybe better call it 'portable ass embly'.
In C, we don't explicitly specify how wide the register/memory unit is, we
use
char/int (short/long, signed/unsigned) to denote the basic unit. I.e.

a=b; // equ. to "mov a,b"

The 2nd difference: Assembly contains too many burdomsom labels. In C, we u
se
'structure', for example:

while(a<b) { // 'while', '(', ')' may be the place for implicit lables
a+=1;
} // '}' is an implicit label

if(a<b) {
} else { // '{', '}' are implicit labels
} // ditto

The 3rd difference: Function calling convention in C is reentrance-able (mo stly).

The 4th difference: Local variable.
(Assembly can theoritically do the same but I don't have impression which o
ne
support this feature.)

Basically, all components map to assembly, we cannot express idea more capa ble,
more expressive than Turing Machine can. ... One consequence is that one ca nnot
really understand C/C++ (or other high-level language) without understand

assembly (C++ is worse in this respect, but skipped here).


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 14/04/2026 15:47, wij wrote:

In attempting writting a simple language, I had a thought of what language is to share. Because I saw many people are stuck in thinking C/C++ (or other high level language) can be so abstract, unlimited 'high level' to mysteriously
solve various human description of idea.

C and assembly are essentially the same, maybe better call it 'portable assembly'.
In C, we don't explicitly specify how wide the register/memory unit is, we use
char/int (short/long, signed/unsigned) to denote the basic unit. I.e.

a=b; // equ. to "mov a,b"

What C's 'a=b' equates to in assembly could be anything, depending on
target machine, the types of 'a' and 'b', their scopes and linkage, the compiler used, and the optimisation levels employed.

The 2nd difference: Assembly contains too many burdomsom labels. In C, we use 'structure', for example:

while(a<b) { // 'while', '(', ')' may be the place for implicit lables
a+=1;
} // '}' is an implicit label

if(a<b) {
} else { // '{', '}' are implicit labels
} // ditto

The 3rd difference: Function calling convention in C is reentrance-able (mostly).

The 4th difference: Local variable.
(Assembly can theoritically do the same but I don't have impression which one support this feature.)

So basically, C and Assembly are NOT essentially the same. C has far
more abstractions: it is a HLL.

And actually, there are at least a couple of language levels I've used
that sit between Assembly and C.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 2026-04-14 at 18:45 +0100, Bart wrote:

On 14/04/2026 15:47, wij wrote:

In attempting writting a simple language, I had a thought of what langu

age is

to share. Because I saw many people are stuck in thinking C/C++ (or oth

er

high level language) can be so abstract, unlimited 'high level' to myst

eriously

solve various human description of idea.

C and assembly are essentially the same, maybe better call it 'portable

assembly'.

In C, we don't explicitly specify how wide the register/memory unit is,

we use

char/int (short/long, signed/unsigned) to denote the basic unit. I.e.

ÿÿ a=b;ÿÿ // equ. to "mov a,b"

What C's 'a=b' equates to in assembly could be anything, depending on

target machine, the types of 'a' and 'b', their scopes and linkage, the

compiler used, and the optimisation levels employed.

The 2nd difference: Assembly contains too many burdomsom labels. In C,

we use

'structure', for example:

ÿÿ while(a<b) {ÿÿ // 'while', '(', ')' may be the p

lace for implicit lables

ÿÿÿÿ a+=1;
ÿÿ }ÿÿÿÿÿÿÿÿÿ?

?ÿÿÿ // '}' is an implicit label

ÿÿ if(a<b) {
ÿÿ } else {ÿÿÿÿÿÿ // '{', '}' a

re implicit labels

ÿÿ }ÿÿÿÿÿÿÿÿÿ?

?ÿÿÿ // ditto

The 3rd difference: Function calling convention in C is reentrance-able

(mostly).

The 4th difference: Local variable.
(Assembly can theoritically do the same but I don't have impression whi

ch one

support this feature.)

So basically, C and Assembly are NOT essentially the same. C has far
more abstractions: it is a HLL.

Anyway, IMO, 'portable assembly' is more descriptive.
'High-Level Language' is anyone's interpretation (prone to mis-interpretati
on and
misunderstanding).

'Assembly' can also be like C:

// This is 'assembly'
def int=32bit; // Choose right bits for your platform, or leave it for
def char= 8bit; // compiler to decide.

int a;
char b;
a=b; // allow auto promotion

while(a<b) {
a+=1;
}

You also can call the above example 'C'. If so, you still have to know how wide
int/char is (Not rare. programmers often struggle which size to use) while

writing "a=b", eventually. What the 'abstracton' really mean? Maybe, even tually
back to int32_t and int8_t after long theoretical/phillisophical pondering?

HHL is just 'style' in favor of specific purpose than the other for me. I a
m not
saying it is wrong, instead it is very helpful (measured by actuall effort
and
gain).

And actually, there are at least a couple of language levels I've used

that sit between Assembly and C.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

wij <wyniijj5@gmail.com> writes:

On Tue, 2026-04-14 at 18:45 +0100, Bart wrote:

On 14/04/2026 15:47, wij wrote:

In attempting writting a simple language, I had a thought of what language is
to share. Because I saw many people are stuck in thinking C/C++ (or other >> > high level language) can be so abstract, unlimited 'high level' to mysteriously
solve various human description of idea.

C and assembly are essentially the same, maybe better call it 'portable assembly'.
In C, we don't explicitly specify how wide the register/memory unit is, we use
char/int (short/long, signed/unsigned) to denote the basic unit. I.e.

ÿÿ a=b;ÿÿ // equ. to "mov a,b"

What C's 'a=b' equates to in assembly could be anything, depending on
target machine, the types of 'a' and 'b', their scopes and linkage, the
compiler used, and the optimisation levels employed.

The 2nd difference: Assembly contains too many burdomsom labels. In C, we use
'structure', for example:

ÿÿ while(a<b) {ÿÿ // 'while', '(', ')' may be the place for implicit lables
ÿÿÿÿ a+=1;
ÿÿ }ÿÿÿÿÿÿÿÿÿÿÿÿÿ // '}' is an implicit label

ÿÿ if(a<b) {
ÿÿ } else {ÿÿÿÿÿÿ // '{', '}' are implicit labels
ÿÿ }ÿÿÿÿÿÿÿÿÿÿÿÿÿ // ditto

The 3rd difference: Function calling convention in C is reentrance-able (mostly).

The 4th difference: Local variable.
(Assembly can theoritically do the same but I don't have impression which one
support this feature.)

So basically, C and Assembly are NOT essentially the same. C has far
more abstractions: it is a HLL.

Anyway, IMO, 'portable assembly' is more descriptive.
'High-Level Language' is anyone's interpretation (prone to mis-interpretation and
misunderstanding).

'Assembly' can also be like C:

// This is 'assembly'
def int=32bit; // Choose right bits for your platform, or leave it for
def char= 8bit; // compiler to decide.

int a;
char b;
a=b; // allow auto promotion

while(a<b) {
a+=1;
}

You also can call the above example 'C'. If so, you still have to know how wide
int/char is (Not rare. programmers often struggle which size to use) while writing "a=b", eventually. What the 'abstracton' really mean? Maybe, eventually
back to int32_t and int8_t after long theoretical/phillisophical pondering?

HHL is just 'style' in favor of specific purpose than the other for me. I am not
saying it is wrong, instead it is very helpful (measured by actuall effort and
gain).

And actually, there are at least a couple of language levels I've used
that sit between Assembly and C.

While I'll grant you that "high-level" is a subjective term, I don't
know that "portable assembly" is quite right either (and also a bit of
an oxymoron).

That said, I think we're splitting hairs here.

--
Regards,
Jonathan Lamothe
https://jlamothe.net

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 14/04/2026 19:41, wij wrote:

On Tue, 2026-04-14 at 18:45 +0100, Bart wrote:

On 14/04/2026 15:47, wij wrote:

In attempting writting a simple language, I had a thought of what language is
to share. Because I saw many people are stuck in thinking C/C++ (or other >>> high level language) can be so abstract, unlimited 'high level' to mysteriously
solve various human description of idea.

C and assembly are essentially the same, maybe better call it 'portable assembly'.
In C, we don't explicitly specify how wide the register/memory unit is, we use
char/int (short/long, signed/unsigned) to denote the basic unit. I.e.

ÿÿ a=b;ÿÿ // equ. to "mov a,b"

What C's 'a=b' equates to in assembly could be anything, depending on
target machine, the types of 'a' and 'b', their scopes and linkage, the
compiler used, and the optimisation levels employed.

The 2nd difference: Assembly contains too many burdomsom labels. In C, we use
'structure', for example:

ÿÿ while(a<b) {ÿÿ // 'while', '(', ')' may be the place for implicit lables
ÿÿÿÿ a+=1;
ÿÿ }ÿÿÿÿÿÿÿÿÿÿÿÿÿ // '}' is an implicit label

ÿÿ if(a<b) {
ÿÿ } else {ÿÿÿÿÿÿ // '{', '}' are implicit labels
ÿÿ }ÿÿÿÿÿÿÿÿÿÿÿÿÿ // ditto

The 3rd difference: Function calling convention in C is reentrance-able (mostly).

The 4th difference: Local variable.
(Assembly can theoritically do the same but I don't have impression which one
support this feature.)

So basically, C and Assembly are NOT essentially the same. C has far
more abstractions: it is a HLL.

Anyway, IMO, 'portable assembly' is more descriptive.
'High-Level Language' is anyone's interpretation (prone to mis-interpretation and
misunderstanding).

'Assembly' can also be like C:

// This is 'assembly'
def int=32bit; // Choose right bits for your platform, or leave it for
def char= 8bit; // compiler to decide.

int a;
char b;
a=b; // allow auto promotion

while(a<b) {
a+=1;
}

You also can call the above example 'C'.

That's because it is pretty much C. It's not like any assembly I've ever
seen!

If so, you still have to know how wide
int/char is (Not rare. programmers often struggle which size to use) while writing "a=b", eventually. What the 'abstracton' really mean? Maybe, eventually
back to int32_t and int8_t after long theoretical/phillisophical pondering?

Wrap the above into a viable C function. Paste it into godbolt.org, then
look at the actual assembly that is generation for combinations of
target, compile and options. All will be different. Some may not even
generate any code for that loop. (You might also try Clang with -emit-llvm.)

Then change the types of a and b, say to floats or pointers, and do it
again. The assembly will changer yet again, even though you've modified nothing else. That is a characteristic of a HLL: you change one small
part, and the generated code changes across the program.

But if you want to call C some kind of assembler, even though it is
several levels above actual assembly, then that's up to you.

HHL is just 'style' in favor of specific purpose than the other for me. I am not
saying it is wrong, instead it is very helpful (measured by actuall effort and
gain).

Below C there are HLAs or high-level assemblers, which at one time were
also called machine-oriented languages, intended for humans to use. And
a little below that might be intermediate languages (ILs), usually machine-generated, intended for compiler backends.

ILs will be target-independent and so portable to some extent. I'd say
that 'portable assembly' fits those better.

(I've implemented, or devised and implemented, all the four levels
discussed here. There are also other languages in this space such as
PL/M, or Forth.)



--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-04-14 23:41, Bart wrote:

But if you want to call C some kind of assembler, even though it is
several levels above actual assembly, then that's up to you.

Can you name and describe a couple of these "several levels above
actual assembly"? (Assembler macros might qualify as one level.)

Beyond the inherent subjective aspects of that or the OP's initial
statement I certainly see "C" closer to the machine than many HLLs.
It certainly depends on where one is coming from; from an abstract
or user-application level or from the machine level.

There was often mentioned here - very much to the despise of the
audience - that there's a lot effort necessary to implement simple
concepts. To jump on that bandwagon; how would, say, Awk's array
construct map[key] = value have to be modeled in (native) "C".
(Note that this simple statement represents an associative array.)

"C" is abstracting from the machine. And the OP's initial statement
"C and assembly are essentially the same" may be nonsense, or just
a sloppy formulation at best. Or just another exaggeration to make
a debatable point about its low-levelness (compared to other HLLs).
More likely is that he wanted to point out the conceptual building
blocks have "structural similarities". (IMO not worth a debate.)

Janis


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

wij <wyniijj5@gmail.com> writes:

In attempting writting a simple language, I had a thought of what language is to share. Because I saw many people are stuck in thinking C/C++ (or other high level language) can be so abstract, unlimited 'high level' to mysteriously
solve various human description of idea.

C and assembly are essentially the same, maybe better call it 'portable assembly'.

No, C is not any kind of assembly. Assembly language and C are
fundamentally different.

An assembly language program specifies a sequence of CPU instructions.

A C program specifies run-time behavior. (A compiler generates CPU instructions behind the scenes to implement that behavior.)

In C, we don't explicitly specify how wide the register/memory unit is, we use
char/int (short/long, signed/unsigned) to denote the basic unit. I.e.

a=b; // equ. to "mov a,b"

(Or "mov b,a" depending on the assembly syntax.)

Nope. `a=b` could translate to a lot of different instruction
sequences. Either or both of the operands could be registers. There
might or might not be different "mov" instructions for integers, pointers, floating-point values. a and b could be large structs, and the
assignment might be translated to a call to memcpy(), or to equivalent
inline code.

Or the assignment might not result in any code at all, if the compiler
can prove that it has no side effects and the value of a is not used.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 14/04/2026 23:20, Janis Papanagnou wrote:

On 2026-04-14 23:41, Bart wrote:

But if you want to call C some kind of assembler, even though it is
several levels above actual assembly, then that's up to you.

Can you name and describe a couple of these "several levels above
actual assembly"?ÿ (Assembler macros might qualify as one level.)

I said C is several levels above, and mentioned 2 categories and 2
specific ones that can be considered to be in-between.

Namely:

* HLAs (high-level assemblers) of various kinds, as this is a broad
category (see note)

* Intermediate languages (IRs/ILs) such as LLVM IR

* Forth

* PL/M (an old one; there was also C--, now dead)


(Note: the one I implemented was called 'Babbage', devised for the GEC
4000 machines. My task was to port it to DEC PDP10. There's something
about it 2/3 down this page: https://en.wikipedia.org/wiki/GEC_4000_series)

Beyond the inherent subjective aspects of that or the OP's initial
statement I certainly see "C" closer to the machine than many HLLs.

I see it as striving to distance itself from the machine as much as
possible! Certainly until C99 when stdint.h came along.

For example:

* Not committing to actual machine types, widths or representations,
such as a 'byte', or 'twos complement'.

* Being vague about the relations between the different integer types

* Not allowing (until standardised after half a century) binary
literals, and still not allowing those to be printed

* Not being allowed to do a dozen things that you KNOW are well-defined
on your target machine, but C says are UB.

It certainly depends on where one is coming from; from an abstract
or user-application level or from the machine level.

There was often mentioned here - very much to the despise of the
audience - that there's a lot effort necessary to implement simple
concepts. To jump on that bandwagon; how would, say, Awk's array
constructÿ map[key] = valueÿ have to be modeled in (native) "C".
(Note that this simple statement represents an associative array.)

"C" is abstracting from the machine. And the OP's initial statement
"C and assembly are essentially the same" may be nonsense

Actually, describing C as 'portable assembly' annoys me which is why I
went into some detail.



--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 2026-04-14 at 15:31 -0700, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

In attempting writting a simple language, I had a thought of what langu

age is

to share. Because I saw many people are stuck in thinking C/C++ (or oth

er

high level language) can be so abstract, unlimited 'high level' to myst

eriously

solve various human description of idea.

C and assembly are essentially the same, maybe better call it 'portable

assembly'.

No, C is not any kind of assembly.ÿ Assembly language and C are
fundamentally different.

An assembly language program specifies a sequence of CPU instructions.

[Repeat] 'Assembly' can also be like C:
// This is 'assembly'
def int=32bit; // Choose right bits for your platform, or leave it for
def char= 8bit; // compiler to decide.

int a;
char b;
a=b; // allow auto promotion

while(a<b) {
a+=1;
}

Yes, the C-like example above specifies exactly a sequence of CPU instructi
ons
(well, small deviation is allowed, and assembly can also have function, mac
ro)

A C program specifies run-time behavior.ÿ (A compiler generates CPU instructions behind the scenes to implement that behavior.)

Being 'portable', it should specify 'run-time behavior', no exact instructi ons.

In C, we don't explicitly specify how wide the register/memory unit is,

we use

char/int (short/long, signed/unsigned) to denote the basic unit. I.e.

ÿ a=b;ÿÿ // equ. to "mov a,b"

(Or "mov b,a" depending on the assembly syntax.)

Nope.ÿ `a=b` could translate to a lot of different instruction
sequences.ÿ Either or both of the operands could be registers.ÿ

There

might or might not be different "mov" instructions for integers, pointers

,

floating-point values.ÿ a and b could be large structs, and the
assignment might be translated to a call to memcpy(), or to equivalent
inline code.

Or the assignment might not result in any code at all, if the compiler
can prove that it has no side effects and the value of a is not used.

[...]

All mentioned could also be implemented in assembly.
Note that I am not saying C is assembly.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 2026-04-14 at 22:41 +0100, Bart wrote:

On 14/04/2026 19:41, wij wrote:

On Tue, 2026-04-14 at 18:45 +0100, Bart wrote:

On 14/04/2026 15:47, wij wrote:

In attempting writting a simple language, I had a thought of what l

anguage is

to share. Because I saw many people are stuck in thinking C/C++ (or

other

high level language) can be so abstract, unlimited 'high level' to

mysteriously

solve various human description of idea.

C and assembly are essentially the same, maybe better call it 'port

able assembly'.

In C, we don't explicitly specify how wide the register/memory unit

is, we use

char/int (short/long, signed/unsigned) to denote the basic unit. I.

e.

ÿÿÿ a=b;ÿÿ // equ. to "mov a,b"

What C's 'a=b' equates to in assembly could be anything, depending

on

target machine, the types of 'a' and 'b', their scopes and linkage, t

he

compiler used, and the optimisation levels employed.

The 2nd difference: Assembly contains too many burdomsom labels. In

C, we use

'structure', for example:

ÿÿÿ while(a<b) {ÿÿ // 'while', '(', ')' ma

y be the place for implicit lables

ÿÿÿÿÿ a+=1;
ÿÿÿ }ÿÿÿÿÿÿÿ?

?ÿÿÿÿÿ // '}' is an implicit label

ÿÿÿ if(a<b) {
ÿÿÿ } else {ÿÿÿÿÿÿ //

'{', '}' are implicit labels

ÿÿÿ }ÿÿÿÿÿÿÿ?

?ÿÿÿÿÿ // ditto

The 3rd difference: Function calling convention in C is reentrance-

able (mostly).

The 4th difference: Local variable.
(Assembly can theoritically do the same but I don't have impression

which one

support this feature.)

So basically, C and Assembly are NOT essentially the same. C has far
more abstractions: it is a HLL.

Anyway, IMO, 'portable assembly' is more descriptive.
'High-Level Language' is anyone's interpretation (prone to mis-interpre

tation and

misunderstanding).

'Assembly' can also be like C:

ÿ // This is 'assembly'
ÿ def int=32bit;ÿÿ // Choose right bits for your platf

orm, or leave it for

ÿ def char= 8bit;ÿ // compiler to decide.

ÿ int a;
ÿ char b;
ÿ a=b;ÿÿ // allow auto promotion

ÿ while(a<b) {
ÿÿÿ a+=1;
ÿ }

You also can call the above example 'C'.

That's because it is pretty much C. It's not like any assembly I've ever

seen!

If so, you still have to know how wide
int/char is (Not rare. programmers often struggle which size to use) wh

ile

writing "a=b", eventually. What the 'abstracton' really mean? Maybe,

eventually

back to int32_t and int8_t after long theoretical/phillisophical ponder

ing?

Wrap the above into a viable C function. Paste it into godbolt.org, then

look at the actual assembly that is generation for combinations of
target, compile and options. All will be different. Some may not even generate any code for that loop. (You might also try Clang with -emit-llv

m.)

Then change the types of a and b, say to floats or pointers, and do it

again. The assembly will changer yet again, even though you've modified

nothing else. That is a characteristic of a HLL: you change one small
part, and the generated code changes across the program.

But if you want to call C some kind of assembler, even though it is
several levels above actual assembly, then that's up to you.

HHL is just 'style' in favor of specific purpose than the other for me.

I am not

saying it is wrong, instead it is very helpful (measured by actuall eff

ort and

gain).

Below C there are HLAs or high-level assemblers, which at one time were

also called machine-oriented languages, intended for humans to use. And

a little below that might be intermediate languages (ILs), usually machine-generated, intended for compiler backends.

ILs will be target-independent and so portable to some extent. I'd say

that 'portable assembly' fits those better.

Do you program (read/write) IL directly?
I am talking about the language that human uses directly.

(I've implemented, or devised and implemented, all the four levels
discussed here. There are also other languages in this space such as
PL/M, or Forth.)

I am not talking about compiler technology.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

wij <wyniijj5@gmail.com> writes:

On Tue, 2026-04-14 at 15:31 -0700, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

In attempting writting a simple language, I had a thought of what language is
to share. Because I saw many people are stuck in thinking C/C++ (or other >> > high level language) can be so abstract, unlimited 'high level' to mysteriously
solve various human description of idea.

C and assembly are essentially the same, maybe better call it 'portable assembly'.

No, C is not any kind of assembly.ÿ Assembly language and C are
fundamentally different.

An assembly language program specifies a sequence of CPU instructions.

[Repeat] 'Assembly' can also be like C:
// This is 'assembly'
def int=32bit; // Choose right bits for your platform, or leave it for
def char= 8bit; // compiler to decide.

Compiler? You said this was assembly.

int a;
char b;
a=b; // allow auto promotion

while(a<b) {
a+=1;
}

You've claimed that that's assembly language. What assembler?
For what CPU?

Is it even for a real assembler?

Yes, the C-like example above specifies exactly a sequence of CPU instructions
(well, small deviation is allowed, and assembly can also have function, macro)

A C program specifies run-time behavior.ÿ (A compiler generates CPU
instructions behind the scenes to implement that behavior.)

Being 'portable', it should specify 'run-time behavior', no exact instructions.

Yes, that's what I said. And that's the fundamental difference between assembly and C.

In C, we don't explicitly specify how wide the register/memory unit is, we use
char/int (short/long, signed/unsigned) to denote the basic unit. I.e.

ÿ a=b;ÿÿ // equ. to "mov a,b"

(Or "mov b,a" depending on the assembly syntax.)

Nope.ÿ `a=b` could translate to a lot of different instruction
sequences.ÿ Either or both of the operands could be registers.ÿ There
might or might not be different "mov" instructions for integers, pointers, >> floating-point values.ÿ a and b could be large structs, and the
assignment might be translated to a call to memcpy(), or to equivalent
inline code.

Or the assignment might not result in any code at all, if the compiler
can prove that it has no side effects and the value of a is not used.

[...]

All mentioned could also be implemented in assembly.

Sure, many C compilers can generate assembly code. But I question your
claim that an assembler can plausibly generate a call to memcpy() for
something that looks like a simple assignment.

Many assemblers support macros, but the assembly language still
specifies the sequence of CPU instructions.

If you can cite a real-world "assembler" that behaves that way,
there might be something to discuss.

Note that I am not saying C is assembly.

You said that "C and assembly are essentially the same, maybe better
call it 'portable assembly'." I disagree.

I had a similar discussion here some time ago. As I recall, the
other participant repeatedly claimed that sophisticated assemblers
that don't generate specified sequences of CPU instructions are
common, but never provided an example. (I haven't been able to
track down the discussion.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

W dniu 14.04.2026 oÿ16:47, wij pisze:

C and assembly are essentially the same

No! C and Assembler are both compile able in to "binary machine code",
which is defined by processor manufacturer. And this is end of any
similarity. Main differences between C and Assembler langs are:

a) Assembler lang is processor manufacturer specific, and is compiler
vendor specific;
b) Above point mean: Assembler has not standardized API nor ABI;
c) Porting Assembler code to another processor always mean rewrite whole
code "from scratch" - you can only reuse algorithms and general code structure, but not earlier coded functions;
d) Assembler lang has different model of code: function declarations and definitions are inseparably. Programmer can call function before it's declaration in code (this is main nonsense in Assembler lang). This sick
code model is widely used in all other langs (except C and C++) and in
all scripting langs;
e) Assembler lang code model, in spite to its illogical approach, has
huge advantage over C code model: it require only 50% code of the same functionality in C lang - read E) point bellow.

A) C lang is standardized, and portable to different processors, microcontrolers, with OS or "bare metal" (without OS);
B) Above point mean: C lang has standardized API and ABI;
C) Porting good C lang code should not require any changes (or can
require some minor tweaks);
D) C lang has different model of code: function declarations and
definitions can be separated. Function declarations can be grouped in separated files called "headers". In order to use any function, first
you must declare it in above code. The only another lang which follow
this rational and 100% logical approach is C++. Even D lang switch back
in to Assembler code model;
E) 100% logical C lang code model require 100% more code to reach the
same functionality. I check this by code the same simple console app in
C++, Bash, Python and in D lang. C++ code was perfectly 100% more LoC
than code in Python and in D lang (both have Assembler code model, and
both have almost the same number of LoC).

To sum up: I don't want answer in this thread because it seems to be
some kind of provoking by claim above quoted nonsense. But I answer
because I can afford half hour or so for writing, because now I am
unemployed and have more free time than in the past.

--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska ??, EU ??;
tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
UWAGA:
NIE ZACI?GAJ "UKRYTEGO D?UGU"! P?A? ZA PROG. FOSS I INFO. INTERNETOWE!
CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

On Tue, 2026-04-14 at 15:31 -0700, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

In attempting writting a simple language, I had a thought of what l

anguage is

to share. Because I saw many people are stuck in thinking C/C++ (or

other

high level language) can be so abstract, unlimited 'high level' to

mysteriously

solve various human description of idea.

C and assembly are essentially the same, maybe better call it 'port

able assembly'.

No, C is not any kind of assembly.ÿ Assembly language and C are fundamentally different.

An assembly language program specifies a sequence of CPU instructions

.

[Repeat] 'Assembly' can also be like C:
ÿ// This is 'assembly'
ÿdef int=32bit;ÿÿ // Choose right bits for your platfo

rm, or leave it for

ÿdef char= 8bit;ÿ // compiler to decide.

Compiler?ÿ You said this was assembly.

ÿint a;
ÿchar b;
ÿa=b;ÿÿ // allow auto promotion

ÿwhile(a<b) {
ÿÿ a+=1;
ÿ}

You've claimed that that's assembly language.ÿ What assembler?
For what CPU?

Is it even for a real assembler?

I think you realize the example above is just an example to demo my idea.

Yes, the C-like example above specifies exactly a sequence of CPU instr

uctions

(well, small deviation is allowed, and assembly can also have function,

macro)

A C program specifies run-time behavior.ÿ (A compiler generates

CPU

instructions behind the scenes to implement that behavior.)

Being 'portable', it should specify 'run-time behavior', no exact instr

uctions.

Yes, that's what I said.ÿ And that's the fundamental difference betw

een

assembly and C.

How/what do you specify 'run-time behavior'? Not based on CPU?

E.g. in C, int types are fixed-size, have range, wrap-around, alignment
and 'atomic','overlapping' properties, you cannot really understand or hide
it and
program C/C++ correctly from the high-level concept of 'integer'.

The point is that C has NO WAY get rid of these (hard-ware) features, no ma tter
how high-level one thinks C is or expect C would be.

In C, we don't explicitly specify how wide the register/memory unit

is, we use

char/int (short/long, signed/unsigned) to denote the basic unit. I.

e.

ÿ a=b;ÿÿ // equ. to "mov a,b"

(Or "mov b,a" depending on the assembly syntax.)

Nope.ÿ `a=b` could translate to a lot of different instruction
sequences.ÿ Either or both of the operands could be registers.

ÿ There

might or might not be different "mov" instructions for integers, poin

ters,

floating-point values.ÿ a and b could be large structs, and the assignment might be translated to a call to memcpy(), or to equivalen

t

inline code.

Or the assignment might not result in any code at all, if the compile

r

can prove that it has no side effects and the value of a is not used.

[...]

All mentioned could also be implemented in assembly.

Sure, many C compilers can generate assembly code.ÿ But I question y

our

claim that an assembler can plausibly generate a call to memcpy() for something that looks like a simple assignment.

Many assemblers support macros, but the assembly language still
specifies the sequence of CPU instructions.

If you can cite a real-world "assembler" that behaves that way,
there might be something to discuss.

Note that I am not saying C is assembly.

You said that "C and assembly are essentially the same, maybe better
call it 'portable assembly'."ÿ I disagree.

I had a similar discussion here some time ago.ÿ As I recall, the
other participant repeatedly claimed that sophisticated assemblers
that don't generate specified sequences of CPU instructions are
common, but never provided an example.ÿ (I haven't been able to
track down the discussion.)

When I heard 'sophisticated assemblers', I would think something like my id
ea of
'portable' assembly, but maybe different.ÿ
One my point should be clear as stated in the above int exampleÿ"... C
has NO WAY
get rid of these (hard-ware) features, no matter how high-levelÿone th
inks C is or
expect C would be."


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 15/04/2026 01:33, Bart wrote:

On 14/04/2026 23:20, Janis Papanagnou wrote:

On 2026-04-14 23:41, Bart wrote:

But if you want to call C some kind of assembler, even though it is
several levels above actual assembly, then that's up to you.

Can you name and describe a couple of these "several levels above
actual assembly"?ÿ (Assembler macros might qualify as one level.)

I said C is several levels above, and mentioned 2 categories and 2
specific ones that can be considered to be in-between.

I agree with a great deal you have written in this thread (at least what
I have read so far). My points below are mainly additional comments
rather than arguments or disagreements. Like you, my disagreement is primarily with wij.

Namely:

* HLAs (high-level assemblers) of various kinds, as this is a broad
category (see note)

When I used to do significant amounts of assembly programming (often on "brain-dead" 8-bit CISC microcontrollers), I would make heavy use of
assembler macros as a way of getting slightly "higher level" assembly.
Even with common assembler tools you can write something that is a kind
of HLA. And then for some targets, there are more sophisticated tools
(or you can write them yourself) for additional higher level constructs.

* Intermediate languages (IRs/ILs) such as LLVM IR

LLVM is probably the best candidate for something that could be called a "portable assembler". It is quite likely that other such "languages"
have been developed and used (perhaps internally in multi-target
compilers), but LLVM's is the biggest and with the widest support.

* Forth

Forth is always a bit difficult to categorise. Many Forth
implementations are done with virtual machines or byte-code
interpreters, raising them above assembly. Others are for stack machine processors (very common in the 4-bit world) where the assembly /is/ a
small Forth language. A lot of Forth tools compile very directly
(giving you the "you get what your code looks like" aspect of assembly), others do more optimisation (for the "you get what your code means"
aspect of high level languages).

* PL/M (an old one; there was also C--, now dead)

I never used PL/M - I'm too young for that! C-- was conceived as a
portable intermediary language that compilers could generate to get cross-target compilation without needing individual target backends. In practice, ordinary C does a good enough job for many transpilers during development, then they can move to LLVM for more control and efficiency
if they see it as worth the effort.

(Note: the one I implemented was called 'Babbage', devised for the GEC
4000 machines. My task was to port it to DEC PDP10. There's something
about it 2/3 down this page: https://en.wikipedia.org/wiki/GEC_4000_series)

Beyond the inherent subjective aspects of that or the OP's initial
statement I certainly see "C" closer to the machine than many HLLs.

I see it as striving to distance itself from the machine as much as possible!

Yes - as much as possible while retaining efficiency.

Certainly until C99 when stdint.h came along.

I would not draw that distinction - indeed, I see the opposite. Prior
to <stdint.h>, your integer type sizes were directly from the target
machine - with <stdint.h> explicitly sized integer types, they are now independent of the target hardware.

C has always intended to be as independent from the machine as
practically possible without compromising efficiency. That's why it has implementation-defined behaviour where it makes a significant difference
(such as the size of integer types), while giving full definitions of
things that can reasonably be widely portable while still being
efficient (and sometimes leaving things undefined to encourage portability).

For example:

* Not committing to actual machine types, widths or representations,
such as a 'byte', or 'twos complement'.

(With C23, two's complement is the only allowed signed integer
representation. There comes a point where something is so dominant that
even C commits it to the standards.)

* Being vague about the relations between the different integer types

* Not allowing (until standardised after half a century) binary
literals, and still not allowing those to be printed

That one is more that no one had bothered standardising binary literals.
The people that wanted them, for the most part, are low-level embedded programmers and their tools already supported them. (And even then,
they are not much used in practice.) Printing in binary is not
something people often want - it is far too cumbersome for numbers, and
if you want to dump a view of some flag register then a custom function
with letters is vastly more useful.

C is standardised on binary - unsigned integer types would not work well
on a non-binary target.

* Not being allowed to do a dozen things that you KNOW are well-defined
on your target machine, but C says are UB.

That is certainly part of it. Things like "signed integer arithmetic overflow" is UB at least partly because C models mathematical integer arithmetic. It does not attempt to mimic the underlying hardware. This
is clearly "high level language" territory - C defines the behaviour of
an abstract machine in terms of mathematics. It is not an "assembler"
that defines operations in terms of hardware instructions.

It certainly depends on where one is coming from; from an abstract
or user-application level or from the machine level.

There was often mentioned here - very much to the despise of the
audience - that there's a lot effort necessary to implement simple
concepts. To jump on that bandwagon; how would, say, Awk's array
constructÿ map[key] = valueÿ have to be modeled in (native) "C".
(Note that this simple statement represents an associative array.)

"C" is abstracting from the machine. And the OP's initial statement
"C and assembly are essentially the same" may be nonsense

Actually, describing C as 'portable assembly' annoys me which is why I
went into some detail.

Indeed.

C is defined in terms of an abstract machine, not hardware. And the C
source code running on this abstract machine only needs to match up with
the actual binary code on the real target machine in very specific and
limited ways - the "observable behaviour" of the program. That's
basically start, stop, volatile accesses and IO. Everything else
follows the "as if" - the compiler needs to generate target code that
works (for observable behaviour) "as if" it had done a direct, na‹ve translation of the source.

As I understand the history - and certainly the practice - of the C
language, it is a language with two goals. One is that it should be
possible to write highly portable C code that can be used on a very wide
range of target systems while remaining efficient. The other is that it should be useable for a lot of target-specific system code.

C has never been, and was never intended to be, a "portable assembly".
It was designed to reduce the need to write assembly code. There is a
huge difference in these concepts.





--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 15/04/2026 08:05, wij wrote:

On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

On Tue, 2026-04-14 at 15:31 -0700, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

In attempting writting a simple language, I had a thought of what language is
to share. Because I saw many people are stuck in thinking C/C++ (or other >>>>> high level language) can be so abstract, unlimited 'high level' to mysteriously
solve various human description of idea.

C and assembly are essentially the same, maybe better call it 'portable assembly'.

No, C is not any kind of assembly.ÿ Assembly language and C are
fundamentally different.

An assembly language program specifies a sequence of CPU instructions.

[Repeat] 'Assembly' can also be like C:
ÿ// This is 'assembly'
ÿdef int=32bit;ÿÿ // Choose right bits for your platform, or leave it for >>> ÿdef char= 8bit;ÿ // compiler to decide.

Compiler?ÿ You said this was assembly.

ÿint a;
ÿchar b;
ÿa=b;ÿÿ // allow auto promotion

ÿwhile(a<b) {
ÿÿ a+=1;
ÿ}

You've claimed that that's assembly language.ÿ What assembler?
For what CPU?

Is it even for a real assembler?

I think you realize the example above is just an example to demo my idea.

In other words, it is imaginary. Hitchen's razor - "What can be
asserted without evidence can also be dismissed without evidence". All
you have shown is that your understanding of what "assembly language"
really is, is questionable.

Yes, the C-like example above specifies exactly a sequence of CPU instructions
(well, small deviation is allowed, and assembly can also have function, macro)

A C program specifies run-time behavior.ÿ (A compiler generates CPU
instructions behind the scenes to implement that behavior.)

Being 'portable', it should specify 'run-time behavior', no exact instructions.

Yes, that's what I said.ÿ And that's the fundamental difference between
assembly and C.

How/what do you specify 'run-time behavior'? Not based on CPU?

Correct.

From the C standard:

"The semantic descriptions in this International Standard describe the behaviour of an abstract machine"


Some aspects of C are given as "implementation-defined behaviour", and
the choice of the details of the behaviour will come primarily from the
target processor and/or OS (if any), within the range allowed in the C standard.

E.g. in C, int types are fixed-size, have range, wrap-around, alignment
and 'atomic','overlapping' properties, you cannot really understand or hide it and
program C/C++ correctly from the high-level concept of 'integer'.

Signed integer types in C do not have wrapping behaviour on overflow - arithmetic overflow is undefined behaviour. Unsigned integer types have modulo behaviour, and thus do not overflow.

And yes, you absolutely /can/ program in C and C++ with a high-level
concept of "integer". Pick integer types that are big enough for the
task in hand, and use them without concern for size, alignment, overflow behaviour (because you are not overflowing them), or other behaviours.
If you need atomic access, use atomic types. Occasionally your code
needs to be so low-level, or you are so concerned about maximal
efficiency, that it is helpful to know the details. Usually, however,
you can concentrate on writing correct code. If you have used an
appropriate type, it will be as efficient as practical.

Understanding the underlying hardware can certainly help you write more efficient code, or at least avoid some inefficiencies. But you don't
need more than a rough idea for most kinds of C and C++ programming.

The point is that C has NO WAY get rid of these (hard-ware) features, no matter
how high-level one thinks C is or expect C would be.

A great many real-world programming languages have limitations or
features that exist because of real-world hardware. They often have
some kind of "integer" type that is implemented as 32-bit or 64-bit,
because that efficiently matches hardware. (For example, Haskell is undoubtedly a high-level language by any standards - it's "Int" type is typically 64-bits (though only guaranteed to hold a range of 30 bits)
and is used far more often than unlimited range "Integer".)

C has more "implementation-defined" behaviours than many high-level
languages. It can be considered as a relatively low-level high-level language. But the language's definition is primarily in terms of an
abstract machine and behavioural semantics, not in terms of hardware or implementation, and thus it is a high-level language and not in any
sense an assembler language.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 15/04/2026 05:20, wij wrote:

On Tue, 2026-04-14 at 22:41 +0100, Bart wrote:

HHL is just 'style' in favor of specific purpose than the other for me. I am not
saying it is wrong, instead it is very helpful (measured by actuall effort and
gain).

Below C there are HLAs or high-level assemblers, which at one time were
also called machine-oriented languages, intended for humans to use. And
a little below that might be intermediate languages (ILs), usually
machine-generated, intended for compiler backends.

ILs will be target-independent and so portable to some extent. I'd say
that 'portable assembly' fits those better.

Do you program (read/write) IL directly?
I am talking about the language that human uses directly.

It is possible to write IL directly, when a textual form of it exists.

Not many do that, but then not many write assembly these days either,
/because more convenient higher level languages exist/, one of them being C.

Why do /you/ think that people prefer to use C to write programs rather
than assembly, if they are 'essentially the same'?

(I've implemented, or devised and implemented, all the four levels
discussed here. There are also other languages in this space such as
PL/M, or Forth.)

I am not talking about compiler technology.

You claimed that C and assembler are at pretty much the same level. I'm
saying that they are not only at different levels, but other levels
exist, and I know because I've used them!

A compiler can choose to translate a language to any of those levels, including C (from a higher level language than C usually).


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 15/04/2026 07:05, wij wrote:

On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:

ÿint a;
ÿchar b;
ÿa=b;ÿÿ // allow auto promotion

ÿwhile(a<b) {
ÿÿ a+=1;
ÿ}

You've claimed that that's assembly language.ÿ What assembler?
For what CPU?

Is it even for a real assembler?

I think you realize the example above is just an example to demo my idea.

So you've invented an 'assembly' syntax that looks exactly like C, in
order to support your notion that C and assembly are really the same thing!

Real assembly generally uses explicit instructions and labels rather
than the implicit ones used here. It would also have limits on the
complexity of expressions. If your pseudo-assembler supports:

a = b+c*f(x,y);

then you've invented a HLL.

Yes, the C-like example above specifies exactly a sequence of CPU instructions
(well, small deviation is allowed, and assembly can also have function, macro)

A C program specifies run-time behavior.ÿ (A compiler generates CPU
instructions behind the scenes to implement that behavior.)

Being 'portable', it should specify 'run-time behavior', no exact instructions.

Yes, that's what I said.ÿ And that's the fundamental difference between
assembly and C.

How/what do you specify 'run-time behavior'? Not based on CPU?

E.g. in C, int types are fixed-size, have range, wrap-around, alignment
and 'atomic','overlapping' properties, you cannot really understand or hide it and
program C/C++ correctly from the high-level concept of 'integer'.

The point is that C has NO WAY get rid of these (hard-ware) features, no matter
how high-level one thinks C is or expect C would be.

There are a dozen or more HLLs that have exactly such a set of integer
types. Actually, those have fixed-width integers with fixed ranges, wrap-around behaviour, twos complement format and so on, even more so
than C.

So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are even
more closely tied to the machine than C is. (In C, built-in types are
not sized, but have mininum widths, and until C23, integer
representation was not specified.)

Would you claim that those are also essentially assembly? If not, why not?

I had a similar discussion here some time ago.ÿ As I recall, the
other participant repeatedly claimed that sophisticated assemblers
that don't generate specified sequences of CPU instructions are
common, but never provided an example.ÿ (I haven't been able to
track down the discussion.)

When I heard 'sophisticated assemblers', I would think something like my idea of
'portable' assembly, but maybe different.
One my point should be clear as stated in the above int exampleÿ"... C has NO WAY
get rid of these (hard-ware) features, no matter how high-levelÿone thinks C is or
expect C would be."

Starting with C23, C has _BitInt, where you can define a 1000000-bit
integer type if you want. (There may be limits as to how big.)

Or a 37-bit type.

While I don't agree with such a feature for this language (partly
/because/ it is a big departure from machine types), it is a
counter-example to your point.




--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 2026-04-15 at 11:21 +0100, Bart wrote:

On 15/04/2026 05:20, wij wrote:

On Tue, 2026-04-14 at 22:41 +0100, Bart wrote:

HHL is just 'style' in favor of specific purpose than the other for

me. I am not

saying it is wrong, instead it is very helpful (measured by actuall

effort and

gain).

Below C there are HLAs or high-level assemblers, which at one time we

re

also called machine-oriented languages, intended for humans to use. A

nd

a little below that might be intermediate languages (ILs), usually machine-generated, intended for compiler backends.

ILs will be target-independent and so portable to some extent. I'd sa

y

that 'portable assembly' fits those better.

Do you program (read/write) IL directly?
I am talking about the language that human uses directly.

It is possible to write IL directly, when a textual form of it exists.

Not many do that, but then not many write assembly these days either, /because more convenient higher level languages exist/, one of them being

C.

Why do /you/ think that people prefer to use C to write programs rather

than assembly, if they are 'essentially the same'?

There are many reasons for those have chose C. I agree the dominant one
is support and convenience.

(I've implemented, or devised and implemented, all the four levels discussed here. There are also other languages in this space such as PL/M, or Forth.)

I am not talking about compiler technology.

You claimed that C and assembler are at pretty much the same level. I'm

saying that they are not only at different levels, but other levels
exist, and I know because I've used them!

A compiler can choose to translate a language to any of those levels, including C (from a higher level language than C usually).

This argument of 'level' seems based on engineering of compiler of multiple languages. My point of view is based on theory of computation and maybe psychological recognition.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 2026-04-15 at 11:46 +0100, Bart wrote:

On 15/04/2026 07:05, wij wrote:

On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:

ÿÿint a;
ÿÿchar b;
ÿÿa=b;ÿÿ // allow auto promotion

ÿÿwhile(a<b) {
ÿÿÿ a+=1;
ÿÿ}

You've claimed that that's assembly language.ÿ What assembler?
For what CPU?

Is it even for a real assembler?

I think you realize the example above is just an example to demo my ide

a.

So you've invented an 'assembly' syntax that looks exactly like C, in
order to support your notion that C and assembly are really the same thin

g!

Exactly. But not really 'invented'. I feagured if anyone wants to implement
a 'portable assembly', he would find it not much different from C (from the example shown, 'structured C'). So, in a sense, not worthy to implement.

Real assembly generally uses explicit instructions and labels rather
than the implicit ones used here. It would also have limits on the complexity of expressions. If your pseudo-assembler supports:

ÿÿÿ a = b+c*f(x,y);

then you've invented a HLL.

You may say that.

Yes, the C-like example above specifies exactly a sequence of CPU i

nstructions

(well, small deviation is allowed, and assembly can also have funct

ion, macro)

A C program specifies run-time behavior.ÿ (A compiler genera

tes CPU

instructions behind the scenes to implement that behavior.)

Being 'portable', it should specify 'run-time behavior', no exact i

nstructions.

Yes, that's what I said.ÿ And that's the fundamental difference

between

assembly and C.

How/what do you specify 'run-time behavior'? Not based on CPU?

E.g. in C, int types are fixed-size, have range, wrap-around, alignment
and 'atomic','overlapping' properties, you cannot really understand or

hide it and

program C/C++ correctly from the high-level concept of 'integer'.

The point is that C has NO WAY get rid of these (hard-ware) features, n

o matter

how high-level one thinks C is or expect C would be.

There are a dozen or more HLLs that have exactly such a set of integer

types. Actually, those have fixed-width integers with fixed ranges, wrap-around behaviour, twos complement format and so on, even more so
than C.

So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are even

more closely tied to the machine than C is. (In C, built-in types are
not sized, but have mininum widths, and until C23, integer
representation was not specified.)

Would you claim that those are also essentially assembly? If not, why not

?

I calim C is (maybe I should use 'may be'. Sometimes I feel the conversatio
n
is difficult) 'portable assembly' is because C (subset) could map to 'assem bly'
and in a sense have to. E.g.

int p2; // p2 is connected to extern hardware

p2=0;
p2=0; // significant (hard-ware knows the second 'touch' triggers diff
erent
// action (or for delay purpose).

And, in union, I don't how 'high-level' can explain the way read/write part
of float object officially.
union {
char carr[sizeof(uint64_t)]; // C++ guarantees sizeof(char)==1
float f;
}

I had a similar discussion here some time ago.ÿ As I recall, the
other participant repeatedly claimed that sophisticated assemblers
that don't generate specified sequences of CPU instructions are
common, but never provided an example.ÿ (I haven't been able to
track down the discussion.)

When I heard 'sophisticated assemblers', I would think something like m

y idea of

'portable' assembly, but maybe different.
One my point should be clear as stated in the above int exampleÿ".

.. C has NO WAY

get rid of these (hard-ware) features, no matter how high-levelÿon

e thinks C is or

expect C would be."

Starting with C23, C has _BitInt, where you can define a 1000000-bit
integer type if you want. (There may be limits as to how big.)

Or a 37-bit type.

While I don't agree with such a feature for this language (partly
/because/ it is a big departure from machine types), it is a
counter-example to your point.

Thanks for the example. I did not stress 'C is assembly', maybe it is
because I saw too many Bonita-type of programming concept to stress 'portab
le
assembly' (also I think it may be helpful to others).

My understand of C is that the development of C is simply from practical ne
eds
(i.e. rare of C is from 'theoretical imagination'). Maybe _BitInt is the sa
me but
I don't know.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 2026-04-15 at 20:21 +0800, wij wrote:

On Wed, 2026-04-15 at 11:46 +0100, Bart wrote:

On 15/04/2026 07:05, wij wrote:

On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:

ÿÿint a;
ÿÿchar b;
ÿÿa=b;ÿÿ // allow auto promotion

ÿÿwhile(a<b) {
ÿÿÿ a+=1;
ÿÿ}

You've claimed that that's assembly language.ÿ What assembler?
For what CPU?

Is it even for a real assembler?

I think you realize the example above is just an example to demo my i

dea.

So you've invented an 'assembly' syntax that looks exactly like C, in

order to support your notion that C and assembly are really the same th

ing!

Exactly. But not really 'invented'. I feagured if anyone wants to impleme

nt

a 'portable assembly', he would find it not much different from C (from t

he

example shown, 'structured C'). So, in a sense, not worthy to implement.

Typo: 'structured assembly'

Real assembly generally uses explicit instructions and labels rather

than the implicit ones used here. It would also have limits on the complexity of expressions. If your pseudo-assembler supports:

ÿÿÿ a = b+c*f(x,y);

then you've invented a HLL.

You may say that.

Yes, the C-like example above specifies exactly a sequence of CPU

instructions

(well, small deviation is allowed, and assembly can also have fun

ction, macro)

A C program specifies run-time behavior.ÿ (A compiler gene

rates CPU

instructions behind the scenes to implement that behavior.)

Being 'portable', it should specify 'run-time behavior', no exact

instructions.

Yes, that's what I said.ÿ And that's the fundamental differenc

e between

assembly and C.

How/what do you specify 'run-time behavior'? Not based on CPU?

E.g. in C, int types are fixed-size, have range, wrap-around, alignme

nt

and 'atomic','overlapping' properties, you cannot really understand o

r hide it and

program C/C++ correctly from the high-level concept of 'integer'.

The point is that C has NO WAY get rid of these (hard-ware) features,

no matter

how high-level one thinks C is or expect C would be.

There are a dozen or more HLLs that have exactly such a set of integer

types. Actually, those have fixed-width integers with fixed ranges, wrap-around behaviour, twos complement format and so on, even more so

than C.

So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are even

more closely tied to the machine than C is. (In C, built-in types are

not sized, but have mininum widths, and until C23, integer
representation was not specified.)

Would you claim that those are also essentially assembly? If not, why n

ot?

I calim C is (maybe I should use 'may be'. Sometimes I feel the conversat

ion

is difficult) 'portable assembly' is because C (subset) could map to 'ass

embly'

and in a sense have to. E.g.

ÿ int p2; // p2 is connected to extern hardware

ÿ p2=0;
ÿ p2=0;ÿ // significant (hard-ware knows the second 'touch' t

riggers different

ÿÿÿÿÿÿÿÿ // action (or for delay

purpose).

And, in union, I don't how 'high-level' can explain the way read/write pa

rt

of float object officially.
ÿ union {
ÿÿÿ char carr[sizeof(uint64_t)];ÿÿ // C++ guaran

tees sizeof(char)==1

ÿÿÿ float f;
ÿ }

Typo: char carr[sizeof(float)];

I had a similar discussion here some time ago.ÿ As I recall, t

he

other participant repeatedly claimed that sophisticated assemblers
that don't generate specified sequences of CPU instructions are
common, but never provided an example.ÿ (I haven't been able t

o

track down the discussion.)

When I heard 'sophisticated assemblers', I would think something like

my idea of

'portable' assembly, but maybe different.
One my point should be clear as stated in the above int exampleÿ

"... C has NO WAY

get rid of these (hard-ware) features, no matter how high-levelÿ

one thinks C is or

expect C would be."

Starting with C23, C has _BitInt, where you can define a 1000000-bit

integer type if you want. (There may be limits as to how big.)

Or a 37-bit type.

While I don't agree with such a feature for this language (partly /because/ it is a big departure from machine types), it is a counter-example to your point.

Thanks for the example. I did not stress 'C is assembly', maybe it is
because I saw too many Bonita-type of programming concept to stress 'port

able

assembly' (also I think it may be helpful to others).

My understand of C is that the development of C is simply from practical

needs

(i.e. rare of C is from 'theoretical imagination'). Maybe _BitInt is the

same but

I don't know.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 15/04/2026 12:52, wij wrote:

On Wed, 2026-04-15 at 11:21 +0100, Bart wrote:

On 15/04/2026 05:20, wij wrote:

On Tue, 2026-04-14 at 22:41 +0100, Bart wrote:

HHL is just 'style' in favor of specific purpose than the other for me. I am not
saying it is wrong, instead it is very helpful (measured by actuall effort and
gain).

Below C there are HLAs or high-level assemblers, which at one time were >>>> also called machine-oriented languages, intended for humans to use. And >>>> a little below that might be intermediate languages (ILs), usually
machine-generated, intended for compiler backends.

ILs will be target-independent and so portable to some extent. I'd say >>>> that 'portable assembly' fits those better.

Do you program (read/write) IL directly?
I am talking about the language that human uses directly.

It is possible to write IL directly, when a textual form of it exists.

Not many do that, but then not many write assembly these days either,
/because more convenient higher level languages exist/, one of them being C. >>
Why do /you/ think that people prefer to use C to write programs rather
than assembly, if they are 'essentially the same'?

There are many reasons for those have chose C. I agree the dominant one
is support and convenience.

(I've implemented, or devised and implemented, all the four levels
discussed here. There are also other languages in this space such as
PL/M, or Forth.)

I am not talking about compiler technology.

You claimed that C and assembler are at pretty much the same level. I'm
saying that they are not only at different levels, but other levels
exist, and I know because I've used them!

A compiler can choose to translate a language to any of those levels,
including C (from a higher level language than C usually).

This argument of 'level' seems based on engineering of compiler of multiple languages. My point of view is based on theory of computation and maybe psychological recognition.

If you take syntax out of the equation, and then 'lower' what's left
(ie. flatten the various abstractions), then probably you can compare
the behaviour of a lot of languages with assembly.

However, those things are exactly what HLLs are about, while that
removing of syntax and lowering is exactly what compilers do.

That's why we use HLLs and not ASM unless we need to.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 15/04/2026 14:21, wij wrote:

On Wed, 2026-04-15 at 11:46 +0100, Bart wrote:

There are a dozen or more HLLs that have exactly such a set of integer
types. Actually, those have fixed-width integers with fixed ranges,
wrap-around behaviour, twos complement format and so on, even more so
than C.

So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are even
more closely tied to the machine than C is. (In C, built-in types are
not sized, but have mininum widths, and until C23, integer
representation was not specified.)

Would you claim that those are also essentially assembly? If not, why not?

I calim C is (maybe I should use 'may be'. Sometimes I feel the conversation is difficult) 'portable assembly' is because C (subset) could map to 'assembly'
and in a sense have to. E.g.

int p2; // p2 is connected to extern hardware

p2=0;
p2=0; // significant (hard-ware knows the second 'touch' triggers different
// action (or for delay purpose).

You are not making any sense. I don't think you understand what C is,
how the language is defined, or how typical C implementations work.

In C, when you write the code above there is /nothing/ to suggest that
there should be two actions. C compilers can - and many will - combine
the two "p2 = 0;" statements. This is critical to understanding why C
is not in any sense an "assembler". In assembly languages, if you write
the equivalent of "p2 = 0;" twice, you get the appropriate opcode twice.
In C, the language do not require an operation for the statement "p2 =
0;". They require that after that statement, any observable behaviour produced by the program will be as if the value 0 had been assigned to
the object "p2". Repeating that same requirement does not change it -
the compiler does not have to have implement "p2 = 0;" twice. (It is
free to do so twice - or two hundred times if it likes. And if the
value of p2 is not used, it can be completely eliminated.)

Have you actually done any C programming at all?



--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

The 4th difference: Local variable.
(Assembly can theoritically do the same but I don't have impression which one support this feature.)

If you are talking about function-local data, there are multiple ways
to do store them in an easy-to-clean-up fashion:

- Volatile registers, for the shortest lived data. Calling other
functions causes them to be overwritten with the function's
return value or irrelevant data.
- Non-volatile registers, for data that need to persist across
function calls. You save the contents of them before using them,
as your caller expects the contents of these registers to be
intact once you return.
- The stack, for long-lived function-local data when you are out of
non-volatile registers. You manipulate a dedicated stack pointer
register to allocate and deallocate space for your data.
- Immediates, and the .rodata (ELF) / .rdata (PE) section, for
constants and tables of constants.

The notion of local variable allows you to ignore all of these in C,
though. Assembly having multiple ways to store local data instead of
one can make things fairly complicated to read, write and debug.

(forwarding to alt.lang.asm because you are comparing C with it)

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 15/04/2026 13:21, wij wrote:

On Wed, 2026-04-15 at 11:46 +0100, Bart wrote:

On 15/04/2026 07:05, wij wrote:

On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:

ÿÿint a;
ÿÿchar b;
ÿÿa=b;ÿÿ // allow auto promotion

ÿÿwhile(a<b) {
ÿÿÿ a+=1;
ÿÿ}

You've claimed that that's assembly language.ÿ What assembler?
For what CPU?

Is it even for a real assembler?

I think you realize the example above is just an example to demo my idea. >>

So you've invented an 'assembly' syntax that looks exactly like C, in
order to support your notion that C and assembly are really the same thing!

Exactly. But not really 'invented'. I feagured if anyone wants to implement
a 'portable assembly', he would find it not much different from C (from the example shown, 'structured C'). So, in a sense, not worthy to implement.

Real assembly generally uses explicit instructions and labels rather
than the implicit ones used here. It would also have limits on the
complexity of expressions. If your pseudo-assembler supports:

ÿÿÿ a = b+c*f(x,y);

then you've invented a HLL.

You may say that.

It sounds like you don't understand the difference between a low-level language and a high-level one.

These days C might be considered mid-level (I call it a lower-level HLL, because so many HLLs are much higher level and more abstract).

Compiling a HLL involves lowering it to a different representation, say
from language A to language B.

But just because that translation happens to be routine, doesn't mean
and A is essentially B.

Yes, the C-like example above specifies exactly a sequence of CPU instructions
(well, small deviation is allowed, and assembly can also have function, macro)

A C program specifies run-time behavior.ÿ (A compiler generates CPU >>>>>> instructions behind the scenes to implement that behavior.)

Being 'portable', it should specify 'run-time behavior', no exact instructions.

Yes, that's what I said.ÿ And that's the fundamental difference between >>>> assembly and C.

How/what do you specify 'run-time behavior'? Not based on CPU?

E.g. in C, int types are fixed-size, have range, wrap-around, alignment
and 'atomic','overlapping' properties, you cannot really understand or hide it and
program C/C++ correctly from the high-level concept of 'integer'.

The point is that C has NO WAY get rid of these (hard-ware) features, no matter
how high-level one thinks C is or expect C would be.

There are a dozen or more HLLs that have exactly such a set of integer
types. Actually, those have fixed-width integers with fixed ranges,
wrap-around behaviour, twos complement format and so on, even more so
than C.

So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are even
more closely tied to the machine than C is. (In C, built-in types are
not sized, but have mininum widths, and until C23, integer
representation was not specified.)

Would you claim that those are also essentially assembly? If not, why not?

I calim C is (maybe I should use 'may be'. Sometimes I feel the conversation is difficult) 'portable assembly' is because C (subset) could map to 'assembly'
and in a sense have to. E.g.

int p2; // p2 is connected to extern hardware

p2=0;
p2=0; // significant (hard-ware knows the second 'touch' triggers different
// action (or for delay purpose).

That won't work in C. 'p2' is likely to be in a register; that extra
write may be elided.

You'd have to use 'volatile' to guard against that. But you still can't control where p2 is put into memory. C /is/ used for this stuff, but all
sorts of special extensions, or compiler specifics, may be employed.

In assembly it's much easier.

And, in union, I don't how 'high-level' can explain the way read/write part of float object officially.
union {
char carr[sizeof(float)]; // C++ guarantees sizeof(char)==1
float f;
}

(Fixed that sizeof.)

I normally use my own systems language. That one is aligned much more
directly to hardware than C is, even though it is marginally higher level.

This is because C is intended to work on possible hardware, while mine
was created to work with one target as a time.

Also, when I started on mine (c. 1982 rather than 1972), hardware was
already standardising on 8-bit bytes, byte-addressed, power-of-two word
sizes, and twos-complement integers.

I don't however consider my language to be a form of assembly for lots
of reasons already mentioned.

Its compilers use 3 internal representations before it gets to native code:

HLL source -> AST -> IL -> MCL -> Native

'MCL' is the internal representation of the native code. If I need ASM
output, then MCL can be dumped into a suitable syntax (I support 4
different ASM syntaxes for x64).

This MCL/ASM itself has abstractions, so the same 'MOV' mnemonic is used
for a dozens of different move instructions that each have different
binary opcodes.



--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

makendo <makendo@makendo.invalid> writes:

The 4th difference: Local variable.
(Assembly can theoritically do the same but I don't have impression which one
support this feature.)

If you are talking about function-local data, there are multiple ways
to do store them in an easy-to-clean-up fashion:

- Volatile registers, for the shortest lived data. Calling other
functions causes them to be overwritten with the function's
return value or irrelevant data.
- Non-volatile registers, for data that need to persist across
function calls. You save the contents of them before using them,
as your caller expects the contents of these registers to be
intact once you return.
- The stack, for long-lived function-local data when you are out of
non-volatile registers. You manipulate a dedicated stack pointer
register to allocate and deallocate space for your data.
- Immediates, and the .rodata (ELF) / .rdata (PE) section, for
constants and tables of constants.

The notion of local variable allows you to ignore all of these in C,
though. Assembly having multiple ways to store local data instead of
one can make things fairly complicated to read, write and debug.

(forwarding to alt.lang.asm because you are comparing C with it)

So what you're saying is that assembly can do anything that any other
arbitrary language (that has to eventually compile down to the same
machine code) can do? This should not be surprising to anyone.

--
Regards,
Jonathan Lamothe
https://jlamothe.net

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 2026-04-15 at 14:24 +0100, Bart wrote:

On 15/04/2026 12:52, wij wrote:

On Wed, 2026-04-15 at 11:21 +0100, Bart wrote:

On 15/04/2026 05:20, wij wrote:

On Tue, 2026-04-14 at 22:41 +0100, Bart wrote:

HHL is just 'style' in favor of specific purpose than the other

for me. I am not

saying it is wrong, instead it is very helpful (measured by act

uall effort and

gain).

Below C there are HLAs or high-level assemblers, which at one tim

e were

also called machine-oriented languages, intended for humans to us

e. And

a little below that might be intermediate languages (ILs), usuall

y

machine-generated, intended for compiler backends.

ILs will be target-independent and so portable to some extent. I'

d say

that 'portable assembly' fits those better.

Do you program (read/write) IL directly?
I am talking about the language that human uses directly.

It is possible to write IL directly, when a textual form of it exists

.

Not many do that, but then not many write assembly these days either, /because more convenient higher level languages exist/, one of them b

eing C.

Why do /you/ think that people prefer to use C to write programs rath

er

than assembly, if they are 'essentially the same'?

There are many reasons for those have chose C. I agree the dominant one
is support and convenience.

(I've implemented, or devised and implemented, all the four level

s

discussed here. There are also other languages in this space such

as

PL/M, or Forth.)

I am not talking about compiler technology.

You claimed that C and assembler are at pretty much the same level. I

'm

saying that they are not only at different levels, but other levels exist, and I know because I've used them!

A compiler can choose to translate a language to any of those levels, including C (from a higher level language than C usually).

This argument of 'level' seems based on engineering of compiler of mult

iple

languages. My point of view is based on theory of computation and maybe psychological recognition.

If you take syntax out of the equation, and then 'lower' what's left
(ie. flatten the various abstractions), then probably you can compare
the behaviour of a lot of languages with assembly.

However, those things are exactly what HLLs are about, while that
removing of syntax and lowering is exactly what compilers do.

That's why we use HLLs and not ASM unless we need to.

I guess yes, every foundamental of computation is the same (e.g. assembly a
nd
TM), yet you might surprise: assembly (or TM) is more powerful than any oth
er
formal 'language' (formal system), including those seen in math/logic.
"Why we use HLL" is a deep question and what AI is now trying to solve.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 2026-04-15 at 15:38 +0200, David Brown wrote:

On 15/04/2026 14:21, wij wrote:

On Wed, 2026-04-15 at 11:46 +0100, Bart wrote:

There are a dozen or more HLLs that have exactly such a set of intege

r

types. Actually, those have fixed-width integers with fixed ranges, wrap-around behaviour, twos complement format and so on, even more so than C.

So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are eve

n

more closely tied to the machine than C is. (In C, built-in types are
not sized, but have mininum widths, and until C23, integer
representation was not specified.)

Would you claim that those are also essentially assembly? If not, why

not?

I calim C is (maybe I should use 'may be'. Sometimes I feel the convers

ation

is difficult) 'portable assembly' is because C (subset) could map to 'a

ssembly'

and in a sense have to. E.g.

ÿÿ int p2; // p2 is connected to extern hardware

ÿÿ p2=0;
ÿÿ p2=0;ÿ // significant (hard-ware knows the second '

touch' triggers different

ÿÿÿÿÿÿÿÿÿ // action (or fo

r delay purpose).

You are not making any sense.ÿ I don't think you understand what C i

s,

how the language is defined, or how typical C implementations work.

I switched from C to C++ 30 years ago. But that is 'theoretical', I see thi
ngs
from real world side.ÿI think you approach 'C' from standard documents
, that is
not the way of understanding. You cannot understand the world by/from readi
ngÿ
the bible.

In C, when you write the code above there is /nothing/ to suggest that

there should be two actions.ÿÿ

As I know, 'old-time' C has no optimization.

C compilers can - and many will - combine
the two "p2 = 0;" statements.ÿ This is critical to understanding w

hy C

is not in any sense an "assembler".ÿ

Not a valid reason.

In assembly languages, if you write
the equivalent of "p2 = 0;" twice, you get the appropriate opcode twice

.

Assembly compiler (or language) can also do the same optimization.

ÿ In C, the language do not require an operation for the statement "

p2 =

0;".ÿ They require that after that statement, any observable behavio

ur

produced by the program will be as if the value 0 had been assigned to

the object "p2".ÿÿ

You need a model now by saying so.

Repeating that same requirement does not change it -
the compiler does not have to have implement "p2 = 0;" twice.ÿ (It

is

free to do so twice - or two hundred times if it likes.ÿ And if the

value of p2 is not used, it can be completely eliminated.)

Have you actually done any C programming at all?

Nope, I quit C (but I keep watching C, since part of C++ is C)



--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 2026-04-15 at 21:40 +0800, makendo wrote:

The 4th difference: Local variable.
(Assembly can theoritically do the same but I don't have impression whi

ch one

support this feature.)

If you are talking about function-local data, there are multiple ways
to do store them in an easy-to-clean-up fashion:

ÿÿ - Volatile registers, for the shortest lived data. Calling o

ther

ÿÿÿÿ functions causes them to be overwritten with the

function's

ÿÿÿÿ return value or irrelevant data.
ÿÿ - Non-volatile registers, for data that need to persist acro

ss

ÿÿÿÿ function calls. You save the contents of them be

fore using them,

ÿÿÿÿ as your caller expects the contents of these reg

isters to be

ÿÿÿÿ intact once you return.
ÿÿ - The stack, for long-lived function-local data when you are

out of

ÿÿÿÿ non-volatile registers. You manipulate a dedicat

ed stack pointer

ÿÿÿÿ register to allocate and deallocate space for yo

ur data.

ÿÿ - Immediates, and the .rodata (ELF) / .rdata (PE) section, f

or

ÿÿÿÿ constants and tables of constants.

The notion of local variable allows you to ignore all of these in C,
though. Assembly having multiple ways to store local data instead of
one can make things fairly complicated to read, write and debug.

(forwarding to alt.lang.asm because you are comparing C with it)

I think the local variable thing (of my trial) depends on the program model (computation model). Thanks for the info, your suggestion relates to more
ÿ
complicated stuff than I encountered (I am compiler newbie).


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

W dniu 15.04.2026 oÿ15:40, makendo pisze:

(forwarding to alt.lang.asm because you are comparing C with it)

Great, but what is wrong with comp.lang.asm ? I subcribe it instead any
ohter asm related groups. Is this wrong aproach?

--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska ??, EU ??;
tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
UWAGA:
NIE ZACI?GAJ "UKRYTEGO D?UGU"! P?A? ZA PROG. FOSS I INFO. INTERNETOWE!
CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 15 Apr 2026 20:23:52 +0200
??Jacek Marcin Jaworski?? <jmj@energokod.gda.pl> wrote:

W dniu 15.04.2026 oÿ15:40, makendo pisze:

(forwarding to alt.lang.asm because you are comparing C with it)

Great, but what is wrong with comp.lang.asm ? I subcribe it instead any ohter asm related groups. Is this wrong aproach?

DYM comp.lang.asm.x86?

comp.lang.asm is an empty header for me on eternal september's feed.

AFAIAA there's no moderator approving posts to clax these days, so I
don't think anything gets posted there.

--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska ??, EU ??;
tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>; Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
UWAGA:
NIE ZACI?GAJ "UKRYTEGO D?UGU"! P?A? ZA PROG. FOSS I INFO. INTERNETOWE!
CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>

sig is overlong, and crowded, IMHO.


--
Bah, and indeed Humbug.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 15/04/2026 18:58, wij wrote:

On Wed, 2026-04-15 at 15:38 +0200, David Brown wrote:

On 15/04/2026 14:21, wij wrote:

On Wed, 2026-04-15 at 11:46 +0100, Bart wrote:

There are a dozen or more HLLs that have exactly such a set of integer >>>> types. Actually, those have fixed-width integers with fixed ranges,
wrap-around behaviour, twos complement format and so on, even more so
than C.

So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are even >>>> more closely tied to the machine than C is. (In C, built-in types are
not sized, but have mininum widths, and until C23, integer
representation was not specified.)

Would you claim that those are also essentially assembly? If not, why not? >>>

I calim C is (maybe I should use 'may be'. Sometimes I feel the conversation
is difficult) 'portable assembly' is because C (subset) could map to 'assembly'
and in a sense have to. E.g.

ÿÿ int p2; // p2 is connected to extern hardware

ÿÿ p2=0;
ÿÿ p2=0;ÿ // significant (hard-ware knows the second 'touch' triggers different
ÿÿÿÿÿÿÿÿÿ // action (or for delay purpose).

You are not making any sense.ÿ I don't think you understand what C is,
how the language is defined, or how typical C implementations work.

I switched from C to C++ 30 years ago.

I don't think you understand C++ either. In the context of this
discussion, it is not different from C.

But that is 'theoretical', I see things
from real world side.ÿI think you approach 'C' from standard documents, that is
not the way of understanding. You cannot understand the world by/from reading the bible.

No, I understand C and C++ from using them in real-world code - as well
as knowing what the code means and what is guaranteed by the language. Practical experience tells you what works well in practice - but
theoretical knowledge tells you what you can expect so that you are not
just programming by luck and "it worked for me when I tried it".

In C, when you write the code above there is /nothing/ to suggest that
there should be two actions.

As I know, 'old-time' C has no optimization.

Nonsense.

Modern C compilers often do more optimisation than older ones, but there
was never a "pre-optimisation" world. Things like eliminating dead
code, or optimising based on knowing that signed integer overflow never
occurs in a correct program, have been around from early tools. I have
used heavily optimising compilers for 30 years.

C compilers can - and many will - combine
the two "p2 = 0;" statements.ÿ This is critical to understanding why C
is not in any sense an "assembler".

Not a valid reason.

What do you mean by that? It's a fact, not a "reason".

In assembly languages, if you write
the equivalent of "p2 = 0;" twice, you get the appropriate opcode twice.

Assembly compiler (or language) can also do the same optimization.

No, assemblers cannot do that - if they did, they would not be
assemblers. An assembler directly translates your instructions from
mnemonic codes (assembly instructions) to binary opcodes. Some
assemblers might have pseudo-instructions that translate to more than
one binary opcode, but always in a specific defined pattern.

ÿ In C, the language do not require an operation for the statement "p2 =
0;".ÿ They require that after that statement, any observable behaviour
produced by the program will be as if the value 0 had been assigned to
the object "p2".

You need a model now by saying so.

Again, I don't know what you are trying to say.

Repeating that same requirement does not change it -
the compiler does not have to have implement "p2 = 0;" twice.ÿ (It is
free to do so twice - or two hundred times if it likes.ÿ And if the
value of p2 is not used, it can be completely eliminated.)

Have you actually done any C programming at all?

Nope, I quit C (but I keep watching C, since part of C++ is C)

Okay, have you ever actually done any C++ programming? The languages
share the same philosophy here.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

W dniu 15.04.2026 oÿ22:01, Kerr-Mudd, John pisze:

On Wed, 15 Apr 2026 20:23:52 +0200
??Jacek Marcin Jaworski??<jmj@energokod.gda.pl> wrote:

W dniu 15.04.2026 oÿ15:40, makendo pisze:

(forwarding to alt.lang.asm because you are comparing C with it)

Great, but what is wrong with comp.lang.asm ? I subcribe it instead any
ohter asm related groups. Is this wrong aproach?

DYM comp.lang.asm.x86?

No!

comp.lang.asm is an empty header for me on eternal september's feed.

After question "is comp.lang.asm moderated?" ecosia.org AI answer today, quote:

The newsgroup comp.lang.asm is generally considered an unmoderated Usenet group. Unlike comp.lang.asm.x86, which is known to be moderated, comp.lang.asm does not have an official moderation process and typically allows posts to appear without prior review.

I see old posts published on comp.lang.asm, and last is yours: "Kenny
Code for DOS", from 2023-04-24, mon. (without any answers).

sig is overlong, and crowded, IMHO.

I have so many things to communicate Poles - this is the reason of bit
sig. But I try to be laconic.

--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska ??, EU ??;
tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
UWAGA:
NIE ZACI?GAJ "UKRYTEGO D?UGU"! P?A? ZA PROG. FOSS I INFO. INTERNETOWE!
CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 2026-04-15 at 15:06 +0100, Bart wrote:

On 15/04/2026 13:21, wij wrote:

On Wed, 2026-04-15 at 11:46 +0100, Bart wrote:

On 15/04/2026 07:05, wij wrote:

On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:

ÿÿÿint a;
ÿÿÿchar b;
ÿÿÿa=b;ÿÿ // allow auto promotion

ÿÿÿwhile(a<b) {
ÿÿÿÿ a+=1;
ÿÿÿ}

You've claimed that that's assembly language.ÿ What assemble

r?

For what CPU?

Is it even for a real assembler?

I think you realize the example above is just an example to demo my

idea.

So you've invented an 'assembly' syntax that looks exactly like C, in order to support your notion that C and assembly are really the same

thing!

Exactly. But not really 'invented'. I feagured if anyone wants to imple

ment

a 'portable assembly', he would find it not much different from C (from

the

example shown, 'structured C'). So, in a sense, not worthy to implement

.

Real assembly generally uses explicit instructions and labels rather
than the implicit ones used here. It would also have limits on the complexity of expressions. If your pseudo-assembler supports:

ÿÿÿÿ a = b+c*f(x,y);

then you've invented a HLL.

You may say that.

It sounds like you don't understand the difference between a low-level

language and a high-level one.

These days C might be considered mid-level (I call it a lower-level HLL,

because so many HLLs are much higher level and more abstract).

Compiling a HLL involves lowering it to a different representation, say

from language A to language B.

But just because that translation happens to be routine, doesn't mean
and A is essentially B.

Yes, the C-like example above specifies exactly a sequence of C

PU instructions

(well, small deviation is allowed, and assembly can also have f

unction, macro)

A C program specifies run-time behavior.ÿ (A compiler ge

nerates CPU

instructions behind the scenes to implement that behavior.)

Being 'portable', it should specify 'run-time behavior', no exa

ct instructions.

Yes, that's what I said.ÿ And that's the fundamental differe

nce between

assembly and C.

How/what do you specify 'run-time behavior'? Not based on CPU?

E.g. in C, int types are fixed-size, have range, wrap-around, align

ment

and 'atomic','overlapping' properties, you cannot really understand

or hide it and

program C/C++ correctly from the high-level concept of 'integer'.

The point is that C has NO WAY get rid of these (hard-ware) feature

s, no matter

how high-level one thinks C is or expect C would be.

There are a dozen or more HLLs that have exactly such a set of intege

r

types. Actually, those have fixed-width integers with fixed ranges, wrap-around behaviour, twos complement format and so on, even more so than C.

So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are eve

n

more closely tied to the machine than C is. (In C, built-in types are
not sized, but have mininum widths, and until C23, integer
representation was not specified.)

Would you claim that those are also essentially assembly? If not, why

not?

I calim C is (maybe I should use 'may be'. Sometimes I feel the convers

ation

is difficult) 'portable assembly' is because C (subset) could map to 'a

ssembly'

and in a sense have to. E.g.

ÿÿ int p2; // p2 is connected to extern hardware

ÿÿ p2=0;
ÿÿ p2=0;ÿ // significant (hard-ware knows the second '

touch' triggers different

ÿÿÿÿÿÿÿÿÿ // action (or fo

r delay purpose).

That won't work in C. 'p2' is likely to be in a register; that extra
write may be elided.

You'd have to use 'volatile' to guard against that. But you still can't

control where p2 is put into memory. C /is/ used for this stuff, but all

sorts of special extensions, or compiler specifics, may be employed.

In assembly it's much easier.

And, in union, I don't how 'high-level' can explain the way read/write

part

of float object officially.
ÿÿ union {
ÿÿÿÿ char carr[sizeof(float)];ÿÿ // C++ g

uarantees sizeof(char)==1

ÿÿÿÿ float f;
ÿÿ }

(Fixed that sizeof.)

I normally use my own systems language. That one is aligned much more directly to hardware than C is, even though it is marginally higher level

.

This is because C is intended to work on possible hardware, while mine

was created to work with one target as a time.

Also, when I started on mine (c. 1982 rather than 1972), hardware was already standardising on 8-bit bytes, byte-addressed, power-of-two word

sizes, and twos-complement integers.

I don't however consider my language to be a form of assembly for lots

of reasons already mentioned.

Its compilers use 3 internal representations before it gets to native cod

e:

ÿÿ HLL source -> AST -> IL -> MCL -> Native

'MCL' is the internal representation of the native code. If I need ASM

output, then MCL can be dumped into a suitable syntax (I support 4
different ASM syntaxes for x64).

This MCL/ASM itself has abstractions, so the same 'MOV' mnemonic is used

for a dozens of different move instructions that each have different
binary opcodes.

I have a Soft-CPU class you might be insterested suitable for various kind
of
script languages. The idea should not be too difficult to implement in C.

--------------------------------------------------------------------------- ----
Wy.Sct.Spu(3wy) Wy.Sct.Spu( 3wy)

NAME
Spu - Class of general purpose Soft-CPU

SYNOPSIS
Except POD types, C structures, all types are declared in namespace
Wy.

#include <CSCall/SctBase.h>

Spu is an object oriented model (class) of Turing Machine that acts like
a general purpose CPU-based computing machine to provide semantics
for
computing languages (for programming or for program communication).
Ap?
plications are both theoretical and practical.

The main differences of Spu and general purpose CPU (or TM) is that
Spu
has no ?register? nor ?flag? (which, along with
others, can be simu?
lated), Spu has only a tape and a stack. The tape is initially em pty.
Every object (referred to as tape variable or cell) in the tape is a llo?
cated via instruction Alloc and identified by a continuous index num ber.
Tape variable can be any C++ type, including Spu.

The instructions of Spu are application definable because they
are
wildly varying from different purposes. Except necessary few, about

30

instructions are defined for convenience for common usage, see man page
Wy.Sct(3wy).
[cut] ....
-------------------------------

The boundary of assembly and HLL is not clear to me.
I had wrote a killer-grade commercial assembly program, it may still be run ning
today after >30 years. My experience is that assembly is not that scary as commonlyÿ
thought, just don't think in low level.ÿ


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 2026-04-15 at 22:11 +0200, David Brown wrote:

On 15/04/2026 18:58, wij wrote:

On Wed, 2026-04-15 at 15:38 +0200, David Brown wrote:

On 15/04/2026 14:21, wij wrote:

On Wed, 2026-04-15 at 11:46 +0100, Bart wrote:

There are a dozen or more HLLs that have exactly such a set of in

teger

types. Actually, those have fixed-width integers with fixed range

s,

wrap-around behaviour, twos complement format and so on, even mor

e so

than C.

So those HLLs (that is, C++, C#, D, Rust, Java, Zig, Go, ...) are

even

more closely tied to the machine than C is. (In C, built-in types

are

not sized, but have mininum widths, and until C23, integer representation was not specified.)

Would you claim that those are also essentially assembly? If not,

why not?

I calim C is (maybe I should use 'may be'. Sometimes I feel the con

versation

is difficult) 'portable assembly' is because C (subset) could map t

o 'assembly'

and in a sense have to. E.g.

ÿÿÿ int p2; // p2 is connected to extern hardware

ÿÿÿ p2=0;
ÿÿÿ p2=0;ÿ // significant (hard-ware knows th

e second 'touch' triggers different

ÿÿÿÿÿÿÿÿÿÿ // act

ion (or for delay purpose).

You are not making any sense.ÿ I don't think you understand what

C is,

how the language is defined, or how typical C implementations work.

I switched from C to C++ 30 years ago.

I don't think you understand C++ either.ÿ In the context of this
discussion, it is not different from C.

But that is 'theoretical', I see things
from real world side.ÿI think you approach 'C' from standard docum

ents, that is

not the way of understanding. You cannot understand the world by/from r

eading

the bible.

No, I understand C and C++ from using them in real-world code - as well

as knowing what the code means and what is guaranteed by the language.

Practical experience tells you what works well in practice - but
theoretical knowledge tells you what you can expect so that you are not

just programming by luck and "it worked for me when I tried it".

In C, when you write the code above there is /nothing/ to suggest tha

t

there should be two actions.

As I know, 'old-time' C has no optimization.

Nonsense.

Modern C compilers often do more optimisation than older ones, but there

was never a "pre-optimisation" world.ÿ Things like eliminating dead

code, or optimising based on knowing that signed integer overflow never

occurs in a correct program, have been around from early tools.ÿ I h

ave

used heavily optimising compilers for 30 years.

C compilers can - and many will - combine
the two "p2 = 0;" statements.ÿ This is critical to understandi

ng why C

is not in any sense an "assembler".

Not a valid reason.

What do you mean by that?ÿ It's a fact, not a "reason".

ÿ In assembly languages, if you write
the equivalent of "p2 = 0;" twice, you get the appropriate opcode t

wice.

Assembly compiler (or language) can also do the same optimization.

No, assemblers cannot do that - if they did, they would not be
assemblers.ÿ An assembler directly translates your instructions from

mnemonic codes (assembly instructions) to binary opcodes.ÿ Some
assemblers might have pseudo-instructions that translate to more than
one binary opcode, but always in a specific defined pattern.

ÿÿ In C, the language do not require an operation for the s

tatement "p2 =

0;".ÿ They require that after that statement, any observable beh

aviour

produced by the program will be as if the value 0 had been assigned t

o

the object "p2".

You need a model now by saying so.

Again, I don't know what you are trying to say.

Repeating that same requirement does not change it -
the compiler does not have to have implement "p2 = 0;" twice.ÿ

(It is

free to do so twice - or two hundred times if it likes.ÿ And if

the

value of p2 is not used, it can be completely eliminated.)

Have you actually done any C programming at all?

Nope, I quit C (but I keep watching C, since part of C++ is C)

Okay, have you ever actually done any C++ programming?ÿ The language

s

share the same philosophy here.

You are really a sick person. Looser of the real world. You just don't know yourself.
I have a gold medal, an aluminum medal and a bronze commemorative plaque (f
or
solving a riddle of Northrop Coorp.). What you have? Well... a paper (paid
for)
and still making false memory everyday for yourself.
I retired at 37, can you?

Ah, recently, you also failed to verify a simple program that proves
3x+1 problem. Fact is not made by mouth (like DJT?), looser.




--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

wij <wyniijj5@gmail.com> writes:

On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

On Tue, 2026-04-14 at 15:31 -0700, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

In attempting writting a simple language, I had a thought of what language is
to share. Because I saw many people are stuck in thinking C/C++ (or other
high level language) can be so abstract, unlimited 'high level' to mysteriously
solve various human description of idea.

C and assembly are essentially the same, maybe better call it 'portable assembly'.

No, C is not any kind of assembly.ÿ Assembly language and C are
fundamentally different.

An assembly language program specifies a sequence of CPU instructions. >> >

[Repeat] 'Assembly' can also be like C:
ÿ// This is 'assembly'
ÿdef int=32bit;ÿÿ // Choose right bits for your platform, or leave it for >> > ÿdef char= 8bit;ÿ // compiler to decide.

Compiler?ÿ You said this was assembly.

ÿint a;
ÿchar b;
ÿa=b;ÿÿ // allow auto promotion

ÿwhile(a<b) {
ÿÿ a+=1;
ÿ}

You've claimed that that's assembly language.ÿ What assembler?
For what CPU?

Is it even for a real assembler?

I think you realize the example above is just an example to demo my idea.

I hadn't. I realize it now that you've admitted it.

In other words, you made it up.

I don't believe there is any real-world assembler that accepts
that syntax. Your example is meaningless.

For every assembler I've used, the assembly language input
unambiguously specifies the sequence of CPU instructions in the
generated object file. Support for macros do not change that;
it just means the mapping is slightly more complicated.

Cite an example of an existing real-world assembler that does not
behave that way, and we might have something interesting to discuss.

Yes, the C-like example above specifies exactly a sequence of CPU instructions
(well, small deviation is allowed, and assembly can also have function, macro)

A C program specifies run-time behavior.ÿ (A compiler generates CPU
instructions behind the scenes to implement that behavior.)

Being 'portable', it should specify 'run-time behavior', no exact instructions.

Yes, that's what I said.ÿ And that's the fundamental difference between
assembly and C.

How/what do you specify 'run-time behavior'? Not based on CPU?

The C standard defines "behavior" as "external appearance or action",
which is admittedly vague. Run-time behavior is what happens when the
program is running on the target system. It includes things like input
and output, either to a console or to files.

The C standard specifies the behavior of this program:

#include <stdio.h>
int main(void) { puts("hello, world"); }

It does so without reference to any CPU. (Of course some CPU will be
used to implement that behavior.)

E.g. in C, int types are fixed-size, have range, wrap-around, alignment
and 'atomic','overlapping' properties, you cannot really understand or hide it and
program C/C++ correctly from the high-level concept of 'integer'.

The point is that C has NO WAY get rid of these (hard-ware) features, no matter
how high-level one thinks C is or expect C would be.

Right, C doesn't directly support abstract mathematical integers.
Of course I agree that C is a lower level language than many others.
Python, for example, has reasonably transparent support for integers
of arbitrary width. Python is a higher level language than C.
(Notably, the Python interpreter is written in C).

That doesn't make C an assembly language.

[...]

When I heard 'sophisticated assemblers', I would think something like
my idea of 'portable' assembly, but maybe different.ÿ One my point
should be clear as stated in the above int exampleÿ"... C has NO WAY
get rid of these (hard-ware) features, no matter how high-levelÿone
thinks C is or expect C would be."

Again, yes, C is a relatively low-level language. And again,
C is not an assembly language.

And again, if you can cite a real-world example of the kind of
"sophisticated assembler" you're talking about, that would be an
interesting data point.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

wij <wyniijj5@gmail.com> writes:

On Wed, 2026-04-15 at 15:38 +0200, David Brown wrote:

[...]

In C, when you write the code above there is /nothing/ to suggest that
there should be two actions.ÿÿ

As I know, 'old-time' C has no optimization.

I'm not sure that's even meaningful. A C compiler translates C
source code to assembly or machine code. That's a non-trivial
transformation. I'm not sure you can even say that such a
transformation doesn't optimize anything.

But ok, given `n = 0; n = 0;` a C compiler *may or may not* generate
two stores to n. If it generates just one, that's an optimization.
But the point is that that kind of optimization is not specified
by the language. For every assembler I've encoutered, such
optimizations are simply not implemented.

[...]

In assembly languages, if you write
the equivalent of "p2 = 0;" twice, you get the appropriate opcode twice.

Assembly compiler (or language) can also do the same optimization.

Oh? Name a real-world assembler (not from your imagination) that does
that kind of optimization. I'd like to read its manual.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

David Brown <david.brown@hesbynett.no> writes:

On 15/04/2026 01:33, Bart wrote:

[...]

Certainly until C99 when stdint.h came along.

I would not draw that distinction - indeed, I see the opposite. Prior
to <stdint.h>, your integer type sizes were directly from the target
machine - with <stdint.h> explicitly sized integer types, they are now independent of the target hardware.

A minor quibble: The sizes of the predefined integer types have
always been determined by the compiler, often mandated by an ABI
for the target platform. The choice is *influenced* by the target
hardware, but not controlled by it. For example, the width of
`long` on x86_64 is likely to be 32 bits on Windows, 64 bits on
other platforms.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

wij <wyniijj5@gmail.com> writes:

On Wed, 2026-04-15 at 22:11 +0200, David Brown wrote:

[...]

Okay, have you ever actually done any C++ programming?ÿ The languages
share the same philosophy here.

You are really a sick person. Looser of the real world. You just don't know yourself.
I have a gold medal, an aluminum medal and a bronze commemorative plaque (for
solving a riddle of Northrop Coorp.). What you have? Well... a paper (paid for)
and still making false memory everyday for yourself.
I retired at 37, can you?

Ah, recently, you also failed to verify a simple program that proves
3x+1 problem. Fact is not made by mouth (like DJT?), looser.

Keep the personal abuse to yourself.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 15/04/2026 22:12, wij wrote:

On Wed, 2026-04-15 at 15:06 +0100, Bart wrote:

The boundary of assembly and HLL is not clear to me.

That seems to be obvious.

I had wrote a killer-grade commercial assembly program, it may still be running
today after >30 years. My experience is that assembly is not that scary as commonly
thought, just don't think in low level.

It's not that scary. Just unergonomic to code in it, taking longer,
being more error prone, much harder to understand, harder to maintain,
much less portable ...



--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 2026-04-15 at 15:12 -0700, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

On Tue, 2026-04-14 at 15:31 -0700, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

In attempting writting a simple language, I had a thought of wh

at language is

to share. Because I saw many people are stuck in thinking C/C++

(or other

high level language) can be so abstract, unlimited 'high level'

to mysteriously

solve various human description of idea.

C and assembly are essentially the same, maybe better call it '

portable assembly'.

No, C is not any kind of assembly.ÿ Assembly language and C

are

fundamentally different.

An assembly language program specifies a sequence of CPU instruct

ions.

[Repeat] 'Assembly' can also be like C:
ÿ// This is 'assembly'
ÿdef int=32bit;ÿÿ // Choose right bits for your pl

atform, or leave it for

ÿdef char= 8bit;ÿ // compiler to decide.

Compiler?ÿ You said this was assembly.

ÿint a;
ÿchar b;
ÿa=b;ÿÿ // allow auto promotion

ÿwhile(a<b) {
ÿÿ a+=1;
ÿ}

You've claimed that that's assembly language.ÿ What assembler?
For what CPU?

Is it even for a real assembler?

I think you realize the example above is just an example to demo my ide

a.

I hadn't.ÿ I realize it now that you've admitted it.

In other words, you made it up.

I don't believe there is any real-world assembler that accepts
that syntax.ÿ Your example is meaningless.

For every assembler I've used, the assembly language input
unambiguously specifies the sequence of CPU instructions in the
generated object file.ÿ Support for macros do not change that;
it just means the mapping is slightly more complicated.

Cite an example of an existing real-world assembler that does not
behave that way, and we might have something interesting to discuss.

Yes, the C-like example above specifies exactly a sequence of CPU i

nstructions

(well, small deviation is allowed, and assembly can also have funct

ion, macro)

A C program specifies run-time behavior.ÿ (A compiler genera

tes CPU

instructions behind the scenes to implement that behavior.)

Being 'portable', it should specify 'run-time behavior', no exact i

nstructions.

Yes, that's what I said.ÿ And that's the fundamental difference

between

assembly and C.

How/what do you specify 'run-time behavior'? Not based on CPU?

The C standard defines "behavior" as "external appearance or action",
which is admittedly vague.ÿ Run-time behavior is what happens when t

he

program is running on the target system.ÿ It includes things like in

put

and output, either to a console or to files.

The C standard specifies the behavior of this program:

ÿÿÿ #include <stdio.h>
ÿÿÿ int main(void) { puts("hello, world"); }

It does so without reference to any CPU.ÿ (Of course some CPU will b

e

used to implement that behavior.)

E.g. in C, int types are fixed-size, have range, wrap-around, alignment
and 'atomic','overlapping' properties, you cannot really understand or

hide it and

program C/C++ correctly from the high-level concept of 'integer'.

The point is that C has NO WAY get rid of these (hard-ware) features, n

o matter

how high-level one thinks C is or expect C would be.

Right, C doesn't directly support abstract mathematical integers.
Of course I agree that C is a lower level language than many others.
Python, for example, has reasonably transparent support for integers
of arbitrary width.ÿ Python is a higher level language than C.
(Notably, the Python interpreter is written in C).

That doesn't make C an assembly language.

[...]

When I heard 'sophisticated assemblers', I would think something like
my idea of 'portable' assembly, but maybe different.ÿÿ One my

point

should be clear as stated in the above int exampleÿ"... C has NO W

AY

get rid of these (hard-ware) features, no matter how high-levelÿon

e

thinks C is or expect C would be."

Again, yes, C is a relatively low-level language.ÿ And again,
C is not an assembly language.

And again, if you can cite a real-world example of the kind of
"sophisticated assembler" you're talking about, that would be an
interesting data point.

--ÿ
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

I had thought questions like yours might have been due to the English probl
em.ÿ
I did not mean C is (equal to) assembly, but C is-a assembly (logic course 101).
And I hope the following code could explain some confusion.

----------------- file s_tut2.cpp
/* Copyright is licensed by GNU LGPL, see file COPYING. by I.J.Wang 2
025

Spu program: 'instruction' is a C++ function:
"Mov a,b" performs the function of C++ expression "a=b"
"Add a,b" performs the function of C++ expression "a+=b"
"Add a,b,c" performs the function of C++ expression "c=a+b"

Build: g++ s_tut2.cpp -lwy
*/
#include <Wy.stdio.h>
#include "CSCall/Sct.h"

using namespace Wy;
using namespace Wy::Sct;

void t0() {
Errno r;
Spu spu;

// Note: In general, program.reserve(...) is needed if non-memcpy_able vari able
// (String) is used. Because this spu program is simple and no error
is
// thrown, we save the trouble.
/* 0 */ spu.add_instr( new Alloc<float>()); // 0 (alloc 3 float)
/* 1 */ spu.add_instr( new Alloc<float>()); // 1
/* 2 */ spu.add_instr( new Alloc<float>()); // 2
/* 3 */ spu.add_instr( new Alloc<String>()); // 3 (alloc 3 String)
/* 4 */ spu.add_instr( new Alloc<String>()); // 4
/* 5 */ spu.add_instr( new Alloc<String>()); // 5
/* 6 */ spu.add_instr( new Mov<float,float>(TpVar(0),1.32)); // init. var.
/* 7 */ spu.add_instr( new Mov<float,float>(TpVar(1),3.2));
/* 8 */ spu.add_instr( new Add<float,float>(TpVar(0),TpVar(1),TpVar(2)));
/* 9 */ spu.add_instr( new Dump<float>(TpVar(2))); // print resut of v(0)+v
(1)
/* 10 */ spu.add_instr( new Dump<char>('\n'));

/* 11 */ spu.add_instr( new Mov<String,const char*>(TpVar(3),"hello "));
/* 12 */ spu.add_instr( new Mov<String,const char*>(TpVar(4),"world\n"));
/* 13 */ spu.add_instr( new Add<String,String>(TpVar(3),TpVar(4)));
/* 14 */ spu.add_instr( new Dump<String>(TpVar(3))); // print result of v(3 )+v(4)
/* 15 */ spu.add_instr( new Free<String>()); // free 3 non-memcpy-able obje
cts
/* 16 */ spu.add_instr( new Free<String>());
/* 17 */ spu.add_instr( new Free<String>());
/* 18 */ spu.add_instr( new Fin(0));

// Note: If implemented, 'the real assembly' would look much better

if((r=spu.tape.reserve(256))!=Ok) { // reserve enough capacity of tap
e for
WY_THROW(r); // non-copy_able object
}
if((r=spu.run( InstrIdx(0) ))!=Ok) { // run the program from InstrIdx(
0)
WY_THROW(r);
}
};

int main(int argc, const char* argv[])
try {
t0();
cout << "OK" WY_ENDL;
return 0;
}
catch(const Errno& e) {
cerr << wrd(e) << WY_ENDL;
return -1; // e.c_errno();
}
catch(...) {
cerr << "main() caught(...)" WY_ENDL;
throw;
};
--------------

The intended 'assembly' of the above should look cleaner:

alloc<float> // float var. at index 0, no name
alloc<float> // float var. at index 1, no name
alloc<float> // ..
alloc<String> // String var. at index 3
alloc<String>
alloc<String>
mov [0], 1.32
mov [1], 3.2
add [0],[1],[2] // [2]= [0]+[1]
dump [2]
dump '\n'
mov [3], "hello " // [3]="hello "
mov [4], "world\n" // [4]="world\n"
add [3], [4] // [3]+=[4]
dump [3] // dump "helo world\n"
free // free allocated var.
free
free
fin // finish

--------
$make s_tut2
$./s_tut2
4.520000
hello world
OK
-----------------------------------

The 'assembly' could be 'structured assembly', but then I felt the
result should not be much different from C...



--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 2026-04-15 at 23:52 +0100, Bart wrote:

On 15/04/2026 22:12, wij wrote:

On Wed, 2026-04-15 at 15:06 +0100, Bart wrote:

The boundary of assembly and HLL is not clear to me.

That seems to be obvious.

I had wrote a killer-grade commercial assembly program, it may still be

running

today after >30 years. My experience is that assembly is not that scary

as commonly

thought, just don't think in low level.

It's not that scary. Just unergonomic to code in it, taking longer,
being more error prone, much harder to understand, harder to maintain,

much less portable ...

Skill. Treat assembly as a chunk. Well document.




--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 16/04/2026 00:30, wij wrote:

On Wed, 2026-04-15 at 23:52 +0100, Bart wrote:

On 15/04/2026 22:12, wij wrote:

On Wed, 2026-04-15 at 15:06 +0100, Bart wrote:

The boundary of assembly and HLL is not clear to me.

That seems to be obvious.

I had wrote a killer-grade commercial assembly program, it may still be running
today after >30 years. My experience is that assembly is not that scary as commonly
thought, just don't think in low level.

It's not that scary. Just unergonomic to code in it, taking longer,
being more error prone, much harder to understand, harder to maintain,
much less portable ...

Skill. Treat assembly as a chunk. Well document.

You're not making sense. It's like saying I should walk everywhere
instead of using my car.

But I don't want to spend two extra hours a day walking and carrying
shopping etc.

What exactly is the benefit of using assembly over a HLL when both can
tackle the task?

When I first started with microprocessors, I first had to build the
hardware, which was programmed in binary. I wrote a hex editor so I
could use a keyboard. Then used that to write an assembler. Then used
the assembler to write a compiler for a simple HLL.

The HLL allowed me to be far more productive than otherwise. Everybody
seems to understand that, except you.

But I have a counter-proposal: why don't you also program in binary
machine code (I'll let you use hex!) instead of assembly? After all it's
just a skill.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

wij <wyniijj5@gmail.com> writes:
[104 lines deleted]

Again, yes, C is a relatively low-level language.ÿ And again,
C is not an assembly language.

And again, if you can cite a real-world example of the kind of
"sophisticated assembler" you're talking about, that would be an
interesting data point.

[signature snipped]

When you post a followup, please trim quoted text that's not relevant to
your reply. And in particular, don't quote signatures.

I had thought questions like yours might have been due to the English problem.ÿ
I did not mean C is (equal to) assembly, but C is-a assembly (logic course 101).

No I don't think there's an English language issue. I understand what
you're saying.

There are a number of programming languages. C is one of them. There
are a number of assembly languages, which are a subset of the set of programming languages.

You claim that C is an assembly language.

You're wrong. C is not an assembly language.

The meaning of "assembly language" is, I believe, reasonably
and consistently well understood. An assembly language program
specifies a particular sequence of CPU instructions as its output,
typically stored in an object file. C is not that.

And I hope the following code could explain some confusion.

[code and 'assembly' snipped]

No, not at all.

[...]

The 'assembly' could be 'structured assembly', but then I felt the
result should not be much different from C...

One last try. I'm going to make a few statements, all of which
I believe to be true. For each one, please indicate whether you
agree or disagree. Feel free to elaborate, but I'm looking for a
yes/no for each.

1. An assembly language program specifies a sequence of CPU
instructions. The mapping might not be simple (e.g., macros),
but it is unambiguous.

2. A C program does not specify a sequence of CPU instructions.
(I'm ignoring inline assembly, which is a non-standard feature and
not what we're talking about.)

3. A C program specifies behavior, without reference to any particular
CPU instructions. (For example, I can write a "hello, world" C
program and compile and execute it on an x86_64 system and an ARM
system. It behaves as specified on both. The two executables have
no CPU instructions in common.)

5. C is a relatively low-level language (compared to Python,
for example).

6. The fact that C is a relatively low-level language does not imply
that C is an assembly language.

7. C is not an assembly language.

If you still think that C is an assembly language, please provide a
definition of the phrase "assembly language".

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

wij <wyniijj5@gmail.com> writes:

[... comparing C and assembly language ...]

Gentlemen,

I understand the natural reaction to want to respond to the kind of
statements being made in this thread. I hope y'all can resist this
natural reaction and not respond to people who persist in making
arguments that are basically isomorphic to saying 1 equals 0.

Thank you for your assistance in this matter.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bart <bc@freeuk.com> writes:

On 16/04/2026 00:30, wij wrote:

On Wed, 2026-04-15 at 23:52 +0100, Bart wrote:

On 15/04/2026 22:12, wij wrote:

On Wed, 2026-04-15 at 15:06 +0100, Bart wrote:

The boundary of assembly and HLL is not clear to me.

That seems to be obvious.

I had wrote a killer-grade commercial assembly program, it may still be running
today after >30 years. My experience is that assembly is not that scary as commonly
thought, just don't think in low level.

It's not that scary. Just unergonomic to code in it, taking longer,
being more error prone, much harder to understand, harder to maintain,
much less portable ...

Skill. Treat assembly as a chunk. Well document.

You're not making sense. It's like saying I should walk everywhere
instead of using my car.

But I don't want to spend two extra hours a day walking and carrying
shopping etc.

What exactly is the benefit of using assembly over a HLL when both can
tackle the task?

When I first started with microprocessors, I first had to build the
hardware, which was programmed in binary. I wrote a hex editor so I
could use a keyboard. Then used that to write an assembler. Then used
the assembler to write a compiler for a simple HLL.

The HLL allowed me to be far more productive than otherwise. Everybody
seems to understand that, except you.

But I have a counter-proposal: why don't you also program in binary
machine code (I'll let you use hex!) instead of assembly? After all
it's just a skill.

Assembly is a great thing to know. It makes it easier to know what's
going on under the hood of higher level languages, and can even help in trouboeshooting and reasoning about how to make your code more efficiet.

Do I think that learning assembly is an asset? Absolutely.

Do I think it's something that a project should be written in directly?
In most cases, absolutely not.

--
Regards,
Jonathan Lamothe
https://jlamothe.net

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-04-16 01:52, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

[...]

[signature snipped]

When you post a followup, please trim quoted text that's not relevant to
your reply. And in particular, don't quote signatures.

The latter was actually (partly) your fault; usually your signatures
are separated by '-- ', but your recent post had '-- ' and was thus
not seen as signature. Of course it could have been manually trimmed
(like the other irrelevant text, as you suggested). :-)

Janis


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 2026-04-15 at 17:14 -0700, Tim Rentsch wrote:

wij <wyniijj5@gmail.com> writes:

[... comparing C and assembly language ...]

Gentlemen,

I understand the natural reaction to want to respond to the kind of statements being made in this thread.ÿ I hope y'all can resist this
natural reaction and not respond to people who persist in making
arguments that are basically isomorphic to saying 1 equals 0.

Thank you for your assistance in this matter.

Maybe you are right. I say A is-a B, one persist to read A is (exactly) B.
I provide help to using assembly. One persist to read I persuade using assembly and give up HLL. What is going on here?


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

wij <wyniijj5@gmail.com> writes:

On Wed, 2026-04-15 at 17:14 -0700, Tim Rentsch wrote:

wij <wyniijj5@gmail.com> writes:

[... comparing C and assembly language ...]

Gentlemen,

I understand the natural reaction to want to respond to the kind of
statements being made in this thread.ÿ I hope y'all can resist this
natural reaction and not respond to people who persist in making
arguments that are basically isomorphic to saying 1 equals 0.

Thank you for your assistance in this matter.

Maybe you are right. I say A is-a B, one persist to read A is (exactly) B.
I provide help to using assembly. One persist to read I persuade using assembly and give up HLL. What is going on here?

You say that C is an assembly language. Nobody here thinks that
you're *equating* C and assembly language. It's obvious that
there are plenty of assembly languages that are not C, and nobody
has said otherwise. I have no idea why you think anyone has that
particular confusion.

At least one person has apparently interpreted your defense of
assembly language (that it isn't as scary as some think it is)
as a claim that we should program in assembly language rather
than in HLLs. You're right, that was a misinterpretation of what
you wrote. I considered mentioning that, but didn't bother.

The issue I've been discussing is your claim that C is an assembly
language. It is not.

I do not intend to post again in this thread until and unless you
post something substantive on that issue.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-04-16 03:27, wij wrote:

On Wed, 2026-04-15 at 17:14 -0700, Tim Rentsch wrote:

wij <wyniijj5@gmail.com> writes:

[... comparing C and assembly language ...]

Gentlemen,

I understand the natural reaction to want to respond to the kind of
statements being made in this thread.ÿ I hope y'all can resist this
natural reaction and not respond to people who persist in making
arguments that are basically isomorphic to saying 1 equals 0.

Thank you for your assistance in this matter.

Maybe you are right. I say A is-a B, one persist to read A is (exactly) B.
I provide help to using assembly. One persist to read I persuade using assembly and give up HLL. What is going on here?

The problem seems to be that you have a different opinion on
(or interpretation of) the meaning of your initial statement
"C and assembly are essentially the same" than most of the
audience.

Also what you then added to "clarify" things (e.g. what your
understanding of an "is-a" relation is) is, to formulate it
cautiously, debatable. (Not that I'd be inclined to debate
on that fuzzy level.)

Those posts appear to me to lack coherence and relatability,
let alone contributing any stressable facts on these points.
Understand that it's difficult to communicate on that basis.

That's IMO all that "is going on here", no more, no less.

Janis


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

So what you're saying is that assembly can do anything that any other arbitrary language (that has to eventually compile down to the same
machine code) can do? This should not be surprising to anyone.

Not really. Just to say that C is indeed abstract, and not same as
assembly. Compiler optimizations will make the abstractness of C more
evident: for example, you can break down a complex process into many
functions tail calling each other, and under -O2, the process will
only take one frame of stack space, instead of naively eating up the
stack with the call chain.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 4/15/2026 12:57 AM, David Brown wrote:
[...]

C has never been, and was never intended to be, a "portable assembly".
It was designed to reduce the need to write assembly code.ÿ There is a
huge difference in these concepts.

Using C++ for raw Applesoft BASIC? Can be done, but why? To prove algos
can be back ported?





--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 4/15/2026 12:57 AM, David Brown wrote:

On 15/04/2026 01:33, Bart wrote:

On 14/04/2026 23:20, Janis Papanagnou wrote:

On 2026-04-14 23:41, Bart wrote:

But if you want to call C some kind of assembler, even though it is
several levels above actual assembly, then that's up to you.

Can you name and describe a couple of these "several levels above
actual assembly"?ÿ (Assembler macros might qualify as one level.)

I said C is several levels above, and mentioned 2 categories and 2
specific ones that can be considered to be in-between.

I agree with a great deal you have written in this thread (at least what
I have read so far).ÿ My points below are mainly additional comments
rather than arguments or disagreements.ÿ Like you, my disagreement is primarily with wij.

Namely:

* HLAs (high-level assemblers) of various kinds, as this is a broad
category (see note)

When I used to do significant amounts of assembly programming (often on "brain-dead" 8-bit CISC microcontrollers), I would make heavy use of assembler macros as a way of getting slightly "higher level" assembly.
Even with common assembler tools you can write something that is a kind
of HLA.ÿ And then for some targets, there are more sophisticated tools
(or you can write them yourself) for additional higher level constructs.

* Intermediate languages (IRs/ILs) such as LLVM IR

LLVM is probably the best candidate for something that could be called a "portable assembler".ÿ It is quite likely that other such "languages"
have been developed and used (perhaps internally in multi-target
compilers), but LLVM's is the biggest and with the widest support.

* Forth

Forth is always a bit difficult to categorise.ÿ Many Forth
implementations are done with virtual machines or byte-code
interpreters, raising them above assembly.ÿ Others are for stack machine processors (very common in the 4-bit world) where the assembly /is/ a
small Forth language.ÿ A lot of Forth tools compile very directly
(giving you the "you get what your code looks like" aspect of assembly), others do more optimisation (for the "you get what your code means"
aspect of high level languages).

* PL/M (an old one; there was also C--, now dead)

I never used PL/M - I'm too young for that!ÿ C-- was conceived as a
portable intermediary language that compilers could generate to get cross-target compilation without needing individual target backends.ÿ In practice, ordinary C does a good enough job for many transpilers during development, then they can move to LLVM for more control and efficiency
if they see it as worth the effort.

(Note: the one I implemented was called 'Babbage', devised for the GEC
4000 machines. My task was to port it to DEC PDP10. There's something
about it 2/3 down this page: https://en.wikipedia.org/wiki/
GEC_4000_series)

Beyond the inherent subjective aspects of that or the OP's initial
statement I certainly see "C" closer to the machine than many HLLs.

I see it as striving to distance itself from the machine as much as
possible!

Yes - as much as possible while retaining efficiency.

Certainly until C99 when stdint.h came along.

I would not draw that distinction - indeed, I see the opposite.ÿ Prior
to <stdint.h>, your integer type sizes were directly from the target
machine - with <stdint.h> explicitly sized integer types, they are now independent of the target hardware.

C has always intended to be as independent from the machine as
practically possible without compromising efficiency.ÿ That's why it has implementation-defined behaviour where it makes a significant difference (such as the size of integer types), while giving full definitions of
things that can reasonably be widely portable while still being
efficient (and sometimes leaving things undefined to encourage
portability).

For example:

* Not committing to actual machine types, widths or representations,
such as a 'byte', or 'twos complement'.

(With C23, two's complement is the only allowed signed integer representation.ÿ There comes a point where something is so dominant that even C commits it to the standards.)

* Being vague about the relations between the different integer types

* Not allowing (until standardised after half a century) binary
literals, and still not allowing those to be printed

That one is more that no one had bothered standardising binary literals.
ÿThe people that wanted them, for the most part, are low-level embedded programmers and their tools already supported them.ÿ (And even then,
they are not much used in practice.)ÿ Printing in binary is not
something people often want - it is far too cumbersome for numbers, and
if you want to dump a view of some flag register then a custom function
with letters is vastly more useful.

C is standardised on binary - unsigned integer types would not work well
on a non-binary target.

* Not being allowed to do a dozen things that you KNOW are well-
defined on your target machine, but C says are UB.

That is certainly part of it.ÿ Things like "signed integer arithmetic overflow" is UB at least partly because C models mathematical integer arithmetic.ÿ It does not attempt to mimic the underlying hardware.ÿ This
is clearly "high level language" territory - C defines the behaviour of
an abstract machine in terms of mathematics.ÿ It is not an "assembler"
that defines operations in terms of hardware instructions.

It certainly depends on where one is coming from; from an abstract
or user-application level or from the machine level.

There was often mentioned here - very much to the despise of the
audience - that there's a lot effort necessary to implement simple
concepts. To jump on that bandwagon; how would, say, Awk's array
constructÿ map[key] = valueÿ have to be modeled in (native) "C".
(Note that this simple statement represents an associative array.)

"C" is abstracting from the machine. And the OP's initial statement
"C and assembly are essentially the same" may be nonsense

Actually, describing C as 'portable assembly' annoys me which is why I
went into some detail.

Indeed.

C is defined in terms of an abstract machine, not hardware.ÿ And the C source code running on this abstract machine only needs to match up with
the actual binary code on the real target machine in very specific and limited ways - the "observable behaviour" of the program.ÿ That's
basically start, stop, volatile accesses and IO.ÿ Everything else
follows the "as if" - the compiler needs to generate target code that
works (for observable behaviour) "as if" it had done a direct, na‹ve translation of the source.

As I understand the history - and certainly the practice - of the C language, it is a language with two goals.ÿ One is that it should be possible to write highly portable C code that can be used on a very wide range of target systems while remaining efficient.ÿ The other is that it should be useable for a lot of target-specific system code.

C has never been, and was never intended to be, a "portable assembly".
It was designed to reduce the need to write assembly code.ÿ There is a
huge difference in these concepts.

Use C to create the ASM, then GAS it... ;^)

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 4/15/2026 11:12 PM, Chris M. Thomasson wrote:

On 4/15/2026 12:57 AM, David Brown wrote:

On 15/04/2026 01:33, Bart wrote:

On 14/04/2026 23:20, Janis Papanagnou wrote:

On 2026-04-14 23:41, Bart wrote:

But if you want to call C some kind of assembler, even though it is >>>>> several levels above actual assembly, then that's up to you.

Can you name and describe a couple of these "several levels above
actual assembly"?ÿ (Assembler macros might qualify as one level.)

I said C is several levels above, and mentioned 2 categories and 2
specific ones that can be considered to be in-between.

I agree with a great deal you have written in this thread (at least
what I have read so far).ÿ My points below are mainly additional
comments rather than arguments or disagreements.ÿ Like you, my
disagreement is primarily with wij.

Namely:

* HLAs (high-level assemblers) of various kinds, as this is a broad
category (see note)

When I used to do significant amounts of assembly programming (often
on "brain-dead" 8-bit CISC microcontrollers), I would make heavy use
of assembler macros as a way of getting slightly "higher level"
assembly. Even with common assembler tools you can write something
that is a kind of HLA.ÿ And then for some targets, there are more
sophisticated tools (or you can write them yourself) for additional
higher level constructs.

* Intermediate languages (IRs/ILs) such as LLVM IR

LLVM is probably the best candidate for something that could be called
a "portable assembler".ÿ It is quite likely that other such
"languages" have been developed and used (perhaps internally in multi-
target compilers), but LLVM's is the biggest and with the widest support.

* Forth

Forth is always a bit difficult to categorise.ÿ Many Forth
implementations are done with virtual machines or byte-code
interpreters, raising them above assembly.ÿ Others are for stack
machine processors (very common in the 4-bit world) where the
assembly /is/ a small Forth language.ÿ A lot of Forth tools compile
very directly (giving you the "you get what your code looks like"
aspect of assembly), others do more optimisation (for the "you get
what your code means" aspect of high level languages).

* PL/M (an old one; there was also C--, now dead)

I never used PL/M - I'm too young for that!ÿ C-- was conceived as a
portable intermediary language that compilers could generate to get
cross-target compilation without needing individual target backends.
In practice, ordinary C does a good enough job for many transpilers
during development, then they can move to LLVM for more control and
efficiency if they see it as worth the effort.

(Note: the one I implemented was called 'Babbage', devised for the
GEC 4000 machines. My task was to port it to DEC PDP10. There's
something about it 2/3 down this page: https://en.wikipedia.org/wiki/
GEC_4000_series)

Beyond the inherent subjective aspects of that or the OP's initial
statement I certainly see "C" closer to the machine than many HLLs.

I see it as striving to distance itself from the machine as much as
possible!

Yes - as much as possible while retaining efficiency.

Certainly until C99 when stdint.h came along.

I would not draw that distinction - indeed, I see the opposite.ÿ Prior
to <stdint.h>, your integer type sizes were directly from the target
machine - with <stdint.h> explicitly sized integer types, they are now
independent of the target hardware.

C has always intended to be as independent from the machine as
practically possible without compromising efficiency.ÿ That's why it
has implementation-defined behaviour where it makes a significant
difference (such as the size of integer types), while giving full
definitions of things that can reasonably be widely portable while
still being efficient (and sometimes leaving things undefined to
encourage portability).

For example:

* Not committing to actual machine types, widths or representations,
such as a 'byte', or 'twos complement'.

(With C23, two's complement is the only allowed signed integer
representation.ÿ There comes a point where something is so dominant
that even C commits it to the standards.)

* Being vague about the relations between the different integer types

* Not allowing (until standardised after half a century) binary
literals, and still not allowing those to be printed

That one is more that no one had bothered standardising binary
literals. ÿÿThe people that wanted them, for the most part, are low-
level embedded programmers and their tools already supported them.
(And even then, they are not much used in practice.)ÿ Printing in
binary is not something people often want - it is far too cumbersome
for numbers, and if you want to dump a view of some flag register then
a custom function with letters is vastly more useful.

C is standardised on binary - unsigned integer types would not work
well on a non-binary target.

* Not being allowed to do a dozen things that you KNOW are well-
defined on your target machine, but C says are UB.

That is certainly part of it.ÿ Things like "signed integer arithmetic
overflow" is UB at least partly because C models mathematical integer
arithmetic.ÿ It does not attempt to mimic the underlying hardware.
This is clearly "high level language" territory - C defines the
behaviour of an abstract machine in terms of mathematics.ÿ It is not
an "assembler" that defines operations in terms of hardware instructions.

It certainly depends on where one is coming from; from an abstract
or user-application level or from the machine level.

There was often mentioned here - very much to the despise of the
audience - that there's a lot effort necessary to implement simple
concepts. To jump on that bandwagon; how would, say, Awk's array
constructÿ map[key] = valueÿ have to be modeled in (native) "C".
(Note that this simple statement represents an associative array.)

"C" is abstracting from the machine. And the OP's initial statement
"C and assembly are essentially the same" may be nonsense

Actually, describing C as 'portable assembly' annoys me which is why
I went into some detail.

Indeed.

C is defined in terms of an abstract machine, not hardware.ÿ And the C
source code running on this abstract machine only needs to match up
with the actual binary code on the real target machine in very
specific and limited ways - the "observable behaviour" of the
program.ÿ That's basically start, stop, volatile accesses and IO.
Everything else follows the "as if" - the compiler needs to generate
target code that works (for observable behaviour) "as if" it had done
a direct, na‹ve translation of the source.

As I understand the history - and certainly the practice - of the C
language, it is a language with two goals.ÿ One is that it should be
possible to write highly portable C code that can be used on a very
wide range of target systems while remaining efficient.ÿ The other is
that it should be useable for a lot of target-specific system code.

C has never been, and was never intended to be, a "portable assembly".
It was designed to reduce the need to write assembly code.ÿ There is a
huge difference in these concepts.

Use C to create the ASM, then GAS it... ;^)

Humm... Actually, is this use of my macro(s), CT_ASB_*, okay for this
little code example I wrote to "help" me write AppleSoft BASIC? Can you
run it, is the code Kosher, so to speak, well, does it work for you or
not...? Any undefined behavior in my macro? The macros seem a bit
hackish, but they seem to work okay for now: ______________________________________
#include <iostream>
#include <sstream>


// Macro kosher? Seems to be...
namespace ct_basic {

struct program_counter {
unsigned long m_origin;
unsigned long m_cur;
unsigned long m_inc;
std::stringstream m_prog;

program_counter(
unsigned long cur = 0,
unsigned long inc = 10
) : m_origin(cur), m_cur(cur), m_inc(inc) {
}

void line(std::stringstream const& line0) {
m_prog << m_cur << " " << line0.str() << std::endl;
m_cur += m_inc;
}
};

#define CT_ASB_LINE(mp_pc, mp_x) \
{ \
std::stringstream line0; \
line0 << mp_x; \
(mp_pc).line(line0); \
}


#define CT_ASB_GOSUB(mp_pc0, mp_pc1, mp_indent) \
CT_ASB_LINE(mp_pc0, mp_indent "GOSUB " << mp_pc1.m_origin)
}


int
main()
{
{
std::cout << "ctBasic testing 123... :^)\n";
std::cout << "__________________________\n";

{

ct_basic::program_counter pc0(100);
ct_basic::program_counter pc1(1000);

// ct_main
{
ct_basic::program_counter& PC = pc0;

CT_ASB_LINE(PC, "REM ct_main");
CT_ASB_LINE(PC, " PRINT \"ct_main\"");
CT_ASB_GOSUB(PC, pc1, " ");
CT_ASB_LINE(PC, "END");
}

// ct_init
{
ct_basic::program_counter& PC = pc1;

CT_ASB_LINE(PC, "REM ct_init");
CT_ASB_LINE(PC, " PRINT \"ct_init\"");
CT_ASB_LINE(PC, "RETURN");
}

std::cout << pc0.m_prog.str() << "\n\n";
std::cout << pc1.m_prog.str() << "\n\n";
}

std::cout << "__________________________\n";
}

std::cout << "Complete! Well, time to test the\n";
std::cout << "generated AppleSoft BASIC";

return 0;
}
______________________________________


Fwiw, I get an output of:

ctBasic testing 123... :^)
__________________________
100 REM ct_main
110 PRINT "ct_main"
120 GOSUB 1000
130 END


1000 REM ct_init
1010 PRINT "ct_init"
1020 RETURN


__________________________
Complete! Well, time to test the
generated AppleSoft BASIC


;^)

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 4/15/2026 9:58 AM, wij wrote:
[...]

Nope, I quit C (but I keep watching C, since part of C++ is C)

C is nice on several levels...

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 4/15/2026 3:48 PM, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

On Wed, 2026-04-15 at 22:11 +0200, David Brown wrote:

[...]

Okay, have you ever actually done any C++ programming?ÿ The languages
share the same philosophy here.

You are really a sick person. Looser of the real world. You just don't know >> yourself.
I have a gold medal, an aluminum medal and a bronze commemorative plaque (for
solving a riddle of Northrop Coorp.). What you have? Well... a paper (paid for)
and still making false memory everyday for yourself.
I retired at 37, can you?

Ah, recently, you also failed to verify a simple program that proves
3x+1 problem. Fact is not made by mouth (like DJT?), looser.

Keep the personal abuse to yourself.

YIKES! ;^o

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 4/15/2026 7:06 AM, Bart wrote:

On 15/04/2026 13:21, wij wrote:

On Wed, 2026-04-15 at 11:46 +0100, Bart wrote:

On 15/04/2026 07:05, wij wrote:

On Tue, 2026-04-14 at 21:46 -0700, Keith Thompson wrote:

ÿÿÿint a;
ÿÿÿchar b;
ÿÿÿa=b;ÿÿ // allow auto promotion

ÿÿÿwhile(a<b) {
ÿÿÿÿ a+=1;
ÿÿÿ}

You've claimed that that's assembly language.ÿ What assembler?
For what CPU?

Is it even for a real assembler?

I think you realize the example above is just an example to demo my
idea.

So you've invented an 'assembly' syntax that looks exactly like C, in
order to support your notion that C and assembly are really the same
thing!

Exactly. But not really 'invented'. I feagured if anyone wants to
implement
a 'portable assembly', he would find it not much different from C
(from the
example shown, 'structured C'). So, in a sense, not worthy to implement.

Real assembly generally uses explicit instructions and labels rather
than the implicit ones used here. It would also have limits on the
complexity of expressions. If your pseudo-assembler supports:

ÿÿÿÿ a = b+c*f(x,y);

then you've invented a HLL.

You may say that.

It sounds like you don't understand the difference between a low-level language and a high-level one.

A high level lang can dump code for a lower level one and vise versa.
Some code of mine created all in C++:

100 REM ct_vfield_applesoft_basic
110 HOME
120 HGR: HCOLOR = 3: VTAB 22
130 PRINT "ct_vfield_applesoft_basic"
140 GOSUB 1000
150 GOSUB 3000
160 SP = 0
170 RS(SP, 0) = 0
180 RS(SP, 1) = -1
190 RS(SP, 2) = 0
200 RS(SP, 3) = 1
210 RS(SP, 4) = 0
220 GOSUB 8000
230 V1(1) = 0: V1(2) = 0: V1(3) = 1: V1(4) = 128
240 GOSUB 6000
245 PRINT "Chris Thomasson's Koch Complete!"
250 END

1000 REM ct_init
1010 PRINT "ct_init"
1020 DIM A0(6)
1030 DIM V0(4)
1040 DIM V1(4)
1050 DIM V2(4)
1060 DIM V3(4)
1070 DIM V4(4)
1080 DIM V5(4)
1090 RN = 3
1100 DIM RS(RN, 16)
1110 GOSUB 2000
1120 RETURN

2000 REM ct_init_plane
2010 PRINT "ct_init_plane"
2020 A0(1) = 279: REM m_plane.m_width
2030 A0(2) = 191: REM m_plane.m_height
2040 A0(3) = 0.0126106: REM m_plane.m_xstep
2050 A0(4) = 0.0126316: REM m_plane.m_ystep
2060 A0(5) = -1.75288: REM m_plane.m_axes.m_xmin
2070 A0(6) = 1.2: REM m_plane.m_axes.m_ymax
2080 RETURN

3000 REM ct_display_plane
3010 PRINT "ct_display_plane"
3020 FOR I0 = 1 TO 6
3030 PRINT "A0("; I0; ") = " A0(I0)
3040 NEXT I0
3050 RETURN

4000 REM ct_project_point
4010 REM PRINT "ct_project_point"
4020 V0(3) = (V0(1) - A0(5)) / A0(3)
4030 V0(4) = (A0(6) - V0(2)) / A0(4)
4040 IF V0(3) < 0 THEN V0(3) = INT(V0(3) - .5)
4050 IF V0(3) >= 0 THEN V0(3) = INT(V0(3) + .5)
4060 IF V0(4) < 0 THEN V0(4) = INT(V0(4) - .5)
4070 IF V0(4) >= 0 THEN V0(4) = INT(V0(4) + .5)
4080 RETURN

5000 REM ct_plot_point
5010 REM PRINT "ct_plot_point"
5020 GOSUB 4000
5030 IF V0(3) > -1 AND V0(3) <= A0(1) AND V0(4) > -1 AND V0(4) <=
A0(2) THEN HPLOT V0(3), V0(4)
5040 RETURN

6000 REM ct_plot_circle
6010 PRINT "ct_plot_circle"
6020 AB = 6.28318 / V1(4)
6030 FOR I1 = 0 TO 6.28318 STEP AB
6040 V0(1) = V1(1) + COS(I1) * V1(3)
6050 V0(2) = V1(2) + SIN(I1) * V1(3)
6060 GOSUB 5000
6070 NEXT I1
6080 RETURN

7000 REM ct_plot_line
7010 PRINT "ct_plot_line"
7020 V0(1) = V5(1): V0(2) = V5(2)
7030 GOSUB 4000
7040 IF V0(3) < 0 THEN V0(3) = 0
7050 IF V0(3) > A0(1) THEN V0(3) = A0(1)
7060 IF V0(4) < 0 THEN V0(4) = 0
7070 IF V0(4) > A0(2) THEN V0(4) = A0(2)
7080 HPLOT V0(3), V0(4)
7090 V0(1) = V5(3): V0(2) = V5(4)
7100 GOSUB 4000
7110 IF V0(3) < 0 THEN V0(3) = 0
7120 IF V0(3) > A0(1) THEN V0(3) = A0(1)
7130 IF V0(4) < 0 THEN V0(4) = 0
7140 IF V0(4) > A0(2) THEN V0(4) = A0(2)
7150 HPLOT TO V0(3), V0(4)
7160 RETURN

8000 REM ct_koch
8010 IF RS(SP, 0) >= RN THEN RETURN
8020 PRINT "ct_koch = "; RS(SP, 0); " "; RS(SP, 1); " "; RS(SP, 2);
" "; RS(SP, 3); " "; RS(SP, 4)"
8030 RS(SP, 5) = RS(SP, 3) - RS(SP, 1) : REM difx
8040 RS(SP, 6) = RS(SP, 4) - RS(SP, 2) : REM dify
8050 RS(SP, 7) = RS(SP, 1) + RS(SP, 5) / 2 : REM dify
8060 RS(SP, 8) = RS(SP, 2) + RS(SP, 6) / 2 : REM dify
8070 RS(SP, 9) = -RS(SP, 6) : REM perpx
8080 RS(SP, 10) = RS(SP, 5) : REM perpy
8090 RS(SP, 11) = RS(SP, 7) + RS(SP, 9) / 3 : REM tipx
8100 RS(SP, 12) = RS(SP, 8) + RS(SP, 10) / 3 : REM tipy
8110 RS(SP, 13) = RS(SP, 1) + RS(SP, 5) / 3 : REM k0x
8120 RS(SP, 14) = RS(SP, 2) + RS(SP, 6) / 3 : REM k0y
8130 RS(SP, 15) = RS(SP, 3) - RS(SP, 5) / 3 : REM k1x
8140 RS(SP, 16) = RS(SP, 4) - RS(SP, 6) / 3 : REM k1y

8145 IF RS(SP, 0) < RN - 1 GOTO 8230
8150 V5(1) = RS(SP, 1): V5(2) = RS(SP, 2): V5(3) = RS(SP, 13): V5(4)
= RS(SP, 14)
8160 GOSUB 7000
8170 V5(1) = RS(SP, 13): V5(2) = RS(SP, 14): V5(3) = RS(SP, 11):
V5(4) = RS(SP, 12)
8180 GOSUB 7000
8190 V5(1) = RS(SP, 11): V5(2) = RS(SP, 12): V5(3) = RS(SP, 15):
V5(4) = RS(SP, 16)
8200 GOSUB 7000
8210 V5(1) = RS(SP, 15): V5(2) = RS(SP, 16): V5(3) = RS(SP, 3):
V5(4) = RS(SP, 4)
8220 GOSUB 7000

8230 REM line 0
8240 SP = SP + 1
8250 RS(SP, 0) = RS(SP - 1, 0) + 1
8260 RS(SP, 1) = RS(SP - 1, 1)
8270 RS(SP, 2) = RS(SP - 1, 2)
8280 RS(SP, 3) = RS(SP - 1, 13)
8290 RS(SP, 4) = RS(SP - 1, 14)
8300 GOSUB 8000
8310 SP = SP - 1
8320 REM line 1
8330 SP = SP + 1
8340 RS(SP, 0) = RS(SP - 1, 0) + 1
8350 RS(SP, 1) = RS(SP - 1, 13)
8360 RS(SP, 2) = RS(SP - 1, 14)
8370 RS(SP, 3) = RS(SP - 1, 11)
8380 RS(SP, 4) = RS(SP - 1, 12)
8390 GOSUB 8000
8400 SP = SP - 1
8410 REM line 2
8420 SP = SP + 1
8430 RS(SP, 0) = RS(SP - 1, 0) + 1
8440 RS(SP, 1) = RS(SP - 1, 11)
8450 RS(SP, 2) = RS(SP - 1, 12)
8460 RS(SP, 3) = RS(SP - 1, 15)
8470 RS(SP, 4) = RS(SP - 1, 16)
8480 GOSUB 8000
8490 SP = SP - 1
8500 REM line 3
8510 SP = SP + 1
8520 RS(SP, 0) = RS(SP - 1, 0) + 1
8530 RS(SP, 1) = RS(SP - 1, 15)
8540 RS(SP, 2) = RS(SP - 1, 16)
8550 RS(SP, 3) = RS(SP - 1, 3)
8560 RS(SP, 4) = RS(SP - 1, 4)
8570 GOSUB 8000
8580 SP = SP - 1
8590 RETURN

Guess the lang?

[...]

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 4/15/2026 4:30 PM, wij wrote:

On Wed, 2026-04-15 at 23:52 +0100, Bart wrote:

On 15/04/2026 22:12, wij wrote:

On Wed, 2026-04-15 at 15:06 +0100, Bart wrote:

The boundary of assembly and HLL is not clear to me.

That seems to be obvious.

I had wrote a killer-grade commercial assembly program, it may still be running
today after >30 years. My experience is that assembly is not that scary as commonly
thought, just don't think in low level.

It's not that scary. Just unergonomic to code in it, taking longer,
being more error prone, much harder to understand, harder to maintain,
much less portable ...

Skill. Treat assembly as a chunk. Well document.

Well crafted asm is not bad. Only used when needed! simple... :^)

I found some of my old asm on the way back machine:

https://web.archive.org/web/20060214112345/http://appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 4/15/2026 11:37 PM, Chris M. Thomasson wrote:

On 4/15/2026 4:30 PM, wij wrote:

On Wed, 2026-04-15 at 23:52 +0100, Bart wrote:

On 15/04/2026 22:12, wij wrote:

On Wed, 2026-04-15 at 15:06 +0100, Bart wrote:

The boundary of assembly and HLL is not clear to me.

That seems to be obvious.

I had wrote a killer-grade commercial assembly program, it may still
be running
today after >30 years. My experience is that assembly is not that
scary as commonly
thought, just don't think in low level.

It's not that scary. Just unergonomic to code in it, taking longer,
being more error prone, much harder to understand, harder to maintain,
much less portable ...

Skill. Treat assembly as a chunk. Well document.

Well crafted asm is not bad. Only used when needed! simple... :^)

I found some of my old asm on the way back machine:

https://web.archive.org/web/20060214112345/http:// appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html

2005, damn time goes on bye, bye... ;^o

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 4/15/2026 11:40 PM, Chris M. Thomasson wrote:

On 4/15/2026 11:37 PM, Chris M. Thomasson wrote:

On 4/15/2026 4:30 PM, wij wrote:

On Wed, 2026-04-15 at 23:52 +0100, Bart wrote:

On 15/04/2026 22:12, wij wrote:

On Wed, 2026-04-15 at 15:06 +0100, Bart wrote:

The boundary of assembly and HLL is not clear to me.

That seems to be obvious.

I had wrote a killer-grade commercial assembly program, it may
still be running
today after >30 years. My experience is that assembly is not that
scary as commonly
thought, just don't think in low level.

It's not that scary. Just unergonomic to code in it, taking longer,
being more error prone, much harder to understand, harder to maintain, >>>> much less portable ...

Skill. Treat assembly as a chunk. Well document.

Well crafted asm is not bad. Only used when needed! simple... :^)

I found some of my old asm on the way back machine:

https://web.archive.org/web/20060214112345/http://
appcore.home.comcast.net/appcore/src/cpu/i686/ac_i686_gcc_asm.html

2005, damn time goes on bye, bye... ;^o

A song for using lang a to gen code for other langs:

Operatique (Internal Struggle Version)

https://youtu.be/A3Qc-2j-6Gc?list=RDGMEMYH9CUrFO7CfLJpaD7UR85w&t=50

;^)

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 16/04/2026 00:43, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:

On 15/04/2026 01:33, Bart wrote:

[...]

Certainly until C99 when stdint.h came along.

I would not draw that distinction - indeed, I see the opposite. Prior
to <stdint.h>, your integer type sizes were directly from the target
machine - with <stdint.h> explicitly sized integer types, they are now
independent of the target hardware.

A minor quibble: The sizes of the predefined integer types have
always been determined by the compiler, often mandated by an ABI
for the target platform. The choice is *influenced* by the target
hardware, but not controlled by it. For example, the width of
`long` on x86_64 is likely to be 32 bits on Windows, 64 bits on
other platforms.

That's more detail that I had included, but entirely correct. The sizes
are determined by the implementation (compiler and standard library,
which need to agree on these things), which in turn is usually
determined by the ABI, which is determined from the OS and target
processor. But along that path there can be differences - such as the
size of "long" on 64-bit Windows compared to 64-bit *nix, or that "int"
is usually 32-bit on 64-bit processors. And there are implementations
where the size of "int" can be picked with compiler flags - for 68k
processors it is not uncommon for compilers to support options for
16-bit or 32-bit "int".


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 15/04/2026 23:38, wij wrote:
<skip drivel>

I don't think there is anything more to be said. You apparently know everything already.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 16/04/2026 06:43, Waldek Hebisch wrote:

David Brown <david.brown@hesbynett.no> wrote:

On 15/04/2026 18:58, wij wrote:

Assembly compiler (or language) can also do the same optimization.

No, assemblers cannot do that - if they did, they would not be
assemblers. An assembler directly translates your instructions from
mnemonic codes (assembly instructions) to binary opcodes. Some
assemblers might have pseudo-instructions that translate to more than
one binary opcode, but always in a specific defined pattern.

Well, as a program assembler is not a compiler. But people talk
about "assembly language" and you can have a compiler that
takes assembly language as an input. This was done by DEC
for VAX assembly. A guy created compilers for 360 assembly,
one targeting 386, another one targetimg Java. Such compilers
to be useful should do same optimization.

You can indeed do that kind of thing. I once used (briefly) a setup
where the assembly output of a simple 8086 C compiler was piped into a converter to turn that into assembly for an 8-bit microcontroller. The results were not particularly efficient, but it was a path from C to
assembly for that microcontroller. (Other more normal C compilers for
that microcontroller were terrible in other ways.) I have also seen
some assembly "post-processors" that aim to clean up or otherwise
optimise assembly - typically the output of C compilers that generate particularly inefficient patterns.

"Assembly language" is a symbolic form of a processor's (real or
virtual) instruction code, combined with helpful features like labels,
address calculations, and other directives. An "assembler" is a program
that translates this into machine code. But assembly language can be
used for plenty of other things - these days I mostly use it to see what
the compiler has generated.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 16/04/2026 02:17, Jonathan Lamothe wrote:

Bart <bc@freeuk.com> writes:

On 16/04/2026 00:30, wij wrote:

On Wed, 2026-04-15 at 23:52 +0100, Bart wrote:

On 15/04/2026 22:12, wij wrote:

On Wed, 2026-04-15 at 15:06 +0100, Bart wrote:

The boundary of assembly and HLL is not clear to me.

That seems to be obvious.

I had wrote a killer-grade commercial assembly program, it may still be running
today after >30 years. My experience is that assembly is not that scary as commonly
thought, just don't think in low level.

It's not that scary. Just unergonomic to code in it, taking longer,
being more error prone, much harder to understand, harder to maintain, >>>> much less portable ...

Skill. Treat assembly as a chunk. Well document.

You're not making sense. It's like saying I should walk everywhere
instead of using my car.

But I don't want to spend two extra hours a day walking and carrying
shopping etc.

What exactly is the benefit of using assembly over a HLL when both can
tackle the task?

When I first started with microprocessors, I first had to build the
hardware, which was programmed in binary. I wrote a hex editor so I
could use a keyboard. Then used that to write an assembler. Then used
the assembler to write a compiler for a simple HLL.

The HLL allowed me to be far more productive than otherwise. Everybody
seems to understand that, except you.

But I have a counter-proposal: why don't you also program in binary
machine code (I'll let you use hex!) instead of assembly? After all
it's just a skill.

Assembly is a great thing to know. It makes it easier to know what's
going on under the hood of higher level languages, and can even help in trouboeshooting and reasoning about how to make your code more efficiet.

Do I think that learning assembly is an asset? Absolutely.

Do I think it's something that a project should be written in directly?
In most cases, absolutely not.

I agree entirely.

I work in the field of small-systems embedded programming (these days,
that means mostly 32-bit ARM devices programmed in C or C++). I see it
as an advantage for programmers in the field to have done some assembly programming - they have a better understanding of what is going on, and
avoid unnecessary pessimisations. People coming to this field from the
world of PC programming often misunderstand how to write efficient code.

(I once had someone ask me for help to improve the speed of their code
on an 8-bit microcontroller. It turned out they had needed to half the
value of an integer variable, and had done it by "x = x * 0.5;".)

It is even an advantage, I think, for programmers to have worked with
some digital electronics design. In electronics, you quickly learn that
you can connect one output to two inputs, but you cannot connect two
outputs to one input without additional electronics (a multiplexer, a
logic gate, etc.). In programming, you often have resources (variables
or something more complicated) with wide scopes - when you think of it
like electronics, you get an immediate understanding of why it is a bad
idea to set or change these resources in different parts of the code
without some kind of coordination.



--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 15/04/2026 01:33, Bart wrote:
...

* Not allowing (until standardised after half a century) binary
literals, and still not allowing those to be printed

The latest draft standard supports %b and %B formats.

...

* Not being allowed to do a dozen things that you KNOW are well-defined
on your target machine, but C says are UB.

If you know they are well-defined on your only target platform, there's
nothing wrong with writing such code. That's part of the reason why C
says the behavior is undefined, rather than requiring that such code be rejected. Implementations are intended to take advantage of that fact
for code that does not need to be portable.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 15 Apr 2026 22:40:55 +0200
??Jacek Marcin Jaworski?? <jmj@energokod.gda.pl> wrote:

W dniu 15.04.2026 oÿ22:01, Kerr-Mudd, John pisze:

On Wed, 15 Apr 2026 20:23:52 +0200
??Jacek Marcin Jaworski??<jmj@energokod.gda.pl> wrote:

W dniu 15.04.2026 oÿ15:40, makendo pisze:

(forwarding to alt.lang.asm because you are comparing C with it)

Great, but what is wrong with comp.lang.asm ? I subcribe it instead any
ohter asm related groups. Is this wrong aproach?

DYM comp.lang.asm.x86?

No!

comp.lang.asm is an empty header for me on eternal september's feed.

After question "is comp.lang.asm moderated?" ecosia.org AI answer today, quote:

The newsgroup comp.lang.asm is generally considered an unmoderated Usenet group. Unlike comp.lang.asm.x86, which is known to be moderated, comp.lang.asm does not have an official moderation process and typically allows posts to appear without prior review.

I see old posts published on comp.lang.asm, and last is yours: "Kenny
Code for DOS", from 2023-04-24, mon. (without any answers).

I've only posted (xposted) asm code to ala, clax and comp. never to
cla.

This post would be a first; I'll see if it gets there.

sig is overlong, and crowded, IMHO.

I have so many things to communicate Poles - this is the reason of bit
sig. But I try to be laconic.

--
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska ??, EU ??;
tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>; Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
UWAGA:
NIE ZACI?GAJ "UKRYTEGO D?UGU"! P?A? ZA PROG. FOSS I INFO. INTERNETOWE!
CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>

--
Bah, and indeed, Humbug

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 2026-04-15 at 19:04 -0700, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

On Wed, 2026-04-15 at 17:14 -0700, Tim Rentsch wrote:

wij <wyniijj5@gmail.com> writes:

[... comparing C and assembly language ...]

Gentlemen,

I understand the natural reaction to want to respond to the kind of statements being made in this thread.ÿ I hope y'all can resist t

his

natural reaction and not respond to people who persist in making arguments that are basically isomorphic to saying 1 equals 0.

Thank you for your assistance in this matter.

Maybe you are right. I say A is-a B, one persist to read A is (exactly)

B.

I provide help to using assembly. One persist to read I persuade using

assembly and give up HLL. What is going on here?

You say that C is an assembly language.ÿ Nobody here thinks that
you're *equating* C and assembly language.ÿ It's obvious that
there are plenty of assembly languages that are not C, and nobody
has said otherwise.ÿ I have no idea why you think anyone has that
particular confusion.

At least one person has apparently interpreted your defense of
assembly language (that it isn't as scary as some think it is)
as a claim that we should program in assembly language rather
than in HLLs.ÿ You're right, that was a misinterpretation of what
you wrote.ÿ I considered mentioning that, but didn't bother.

The issue I've been discussing is your claim that C is an assembly
language.ÿ It is not.

If I said C is assembly is in the sense that have at least shown in the las
t
post (s_tut2.cpp), where even 'instruction' can be any function (e.g. chang
e
directory, copy files, launch an editor,...). And also, what is 'computatio
n'
is demonstrated, which include suggestion what C is, essentially any progra
m,
and in this sense what HLL is. Finally, it could demonstrate the meaning an
d
testify Church-Turing thesis (my words: no computation language, including

various kind of math formula, can exceeds the expressive power of TM).

It seem you insist C and assembly have to be exactly what your bible says.
If
so, I would say what C standard (I cannot read it) says is the meaning of terminology of term in it, not intended to be anything used in any other si tuation.

I do not intend to post again in this thread until and unless you
post something substantive on that issue.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-04-16 08:37, Chris M. Thomasson wrote:

Well crafted asm is not bad. Only used when needed! simple... :^)

And in practice a throwaway-product once you change platform.
(I'm shuddering thinking about porting my decades old DSP asm
code to some other platform/CPU architecture.) But I've ported
or re-used old "C" code without much effort. This is a crucial
differences, especially in the light of the thread-theses.

Janis


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <86qzof7od4.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

wij <wyniijj5@gmail.com> writes:

[... comparing C and assembly language ...]

Gentlemen,

I understand the natural reaction to want to respond to the kind of >statements being made in this thread. I hope y'all can resist this
natural reaction and not respond to people who persist in making
arguments that are basically isomorphic to saying 1 equals 0.

Thank you for your assistance in this matter.

Thank you. This is one of the people that made comp.theory
utterly useless; indulging him here could do the same to
comp.lang.c. As Tim put it, please avoid.

- Dan C.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <1e4ef965d5ee27013e0abfd3c5dc18831400ad5f.camel@gmail.com>,
wij <wyniijj5@gmail.com> wrote:
...

It seem you insist C and assembly have to be exactly what your bible says.
If so, I would say what C standard (I cannot read it) says is the meaning
of terminology of term in it, not intended to be anything used in any
other situation.

Keith is the king of this newsgroup. What he says, goes.
The way he defines words is the law, and all must fall in line with that.

You're new around here, so you are probably not familar with these rules,
but you will be soon (if you choose to stick around).

Kind Keith then stated:

I do not intend to post again in this thread until and unless you
post something substantive on that issue.

For which we are all grateful.

--
When someone tells me he/she is a Christian I check to see if I'm
still in possession of my wallet.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 2026-04-16 at 18:42 +0800, wij wrote:

On Wed, 2026-04-15 at 19:04 -0700, Keith Thompson wrote:

wij <wyniijj5@gmail.com> writes:

On Wed, 2026-04-15 at 17:14 -0700, Tim Rentsch wrote:

wij <wyniijj5@gmail.com> writes:

[... comparing C and assembly language ...]

Gentlemen,

I understand the natural reaction to want to respond to the kind of statements being made in this thread.ÿ I hope y'all can resist

this

natural reaction and not respond to people who persist in making arguments that are basically isomorphic to saying 1 equals 0.

Thank you for your assistance in this matter.

Maybe you are right. I say A is-a B, one persist to read A is (exactl

y) B.

I provide help to using assembly. One persist to read I persuade usin

g

assembly and give up HLL. What is going on here?

You say that C is an assembly language.ÿ Nobody here thinks that
you're *equating* C and assembly language.ÿ It's obvious that
there are plenty of assembly languages that are not C, and nobody
has said otherwise.ÿ I have no idea why you think anyone has that particular confusion.

At least one person has apparently interpreted your defense of
assembly language (that it isn't as scary as some think it is)
as a claim that we should program in assembly language rather
than in HLLs.ÿ You're right, that was a misinterpretation of what
you wrote.ÿ I considered mentioning that, but didn't bother.

The issue I've been discussing is your claim that C is an assembly language.ÿ It is not.

If I said C is assembly is in the sense that have at least shown in the l

ast

post (s_tut2.cpp), where even 'instruction' can be any function (e.g. cha

nge

directory, copy files, launch an editor,...). And also, what is 'computat

ion'

is demonstrated, which include suggestion what C is, essentially any prog

ram,

and in this sense what HLL is. Finally, it could demonstrate the meaning

and

testify Church-Turing thesis (my words: no computation language, includin

gÿ

various kind of math formula, can exceeds the expressive power of TM).

It seem you insist C and assembly have to be exactly what your bible says

. If

so, I would say what C standard (I cannot read it) says is the meaning of terminology of term in it, not intended to be anything used in any other

situation.

I do not intend to post again in this thread until and unless you
post something substantive on that issue.

(continue)
IMO, C standard is like book of legal terms. Like many symbols in the heade
r
file, it defines one symbol in anoter symbol. The real meaning is not fixed
.
The result is you cannot 'prove' correctness of the source program, even

consistency is a problem.

'Instruction' is low-level? Yes, by definition, but not as one might think. Instruction could refer to a processing unit (might be like the x87 math

co-processor, which may even be more higher level to process expression,...
)
As good chance of C is to find a good function that can be hardwired.

So, the basic feature of HLL is 'structured' (or 'nested') text which remov
es
labels. Semantics is inventor's imagination. So, avoid bizarre complexity,
it
won't add express power to the language, just a matter of short or lengthy
ÿ
expression of programming idea.


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 2026-04-16 at 13:10 +0000, Kenny McCormack wrote:

In article <1e4ef965d5ee27013e0abfd3c5dc18831400ad5f.camel@gmail.com>,
wijÿ <wyniijj5@gmail.com> wrote:
...

It seem you insist C and assembly have to be exactly what your bible sa

ys.

If so, I would say what C standard (I cannot read it) says is the meani

ng

of terminology of term in it, not intended to be anything used in any
other situation.

Keith is the king of this newsgroup.ÿ What he says, goes.
The way he defines words is the law, and all must fall in line with that.

Forget about that, fact first. There are LLM. This is not court.

As I know, comp.lang.c should be a forum for more general topics than lang.c.mod, comp.lang.c.std. And,ÿrefrain from telling what other shou
ld do,
you are just another participant.

You're new around here, so you are probably not familar with these rules,
but you will be soon (if you choose to stick around).

Kind Keith then stated:

I do not intend to post again in this thread until and unless you
post something substantive on that issue.

For which we are all grateful.

comp.lang.c allows idiots (not all, but maybe including me)


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

antispam@fricas.org (Waldek Hebisch) writes:

David Brown <david.brown@hesbynett.no> wrote:

On 15/04/2026 18:58, wij wrote:

Assembly compiler (or language) can also do the same optimization.

No, assemblers cannot do that - if they did, they would not be
assemblers. An assembler directly translates your instructions from
mnemonic codes (assembly instructions) to binary opcodes. Some
assemblers might have pseudo-instructions that translate to more than
one binary opcode, but always in a specific defined pattern.

Well, as a program assembler is not a compiler. But people talk
about "assembly language" and you can have a compiler that
takes assembly language as an input. This was done by DEC
for VAX assembly. A guy created compilers for 360 assembly,
one targeting 386, another one targetimg Java. Such compilers
to be useful should do same optimization.

The C compiler in the GNU Compiler Collection provides
a mechanism to 'take assembly language as an input'
in the form of in-line assembler fragments. It's
useful in some limited cases (machine-level software like
kernels, boot loaders and the like).

The Burroughs Large systems (B5500 and descendents) has
never had an assembler; all code is written in a flavor
of Algol (with special syntax extensions required for
the MCP and other privileged applications).

The Burroughs Medium systems COBOL68 compiler supported
the 'ENTER SYMBOLIC' statement, which was followed by
in-line assembler until the LEAVE SYMBOLIC statement.

That functionality was not present in COBOL74 and
COBOL85 compilers. The Burroughs Programming Language
(BPL) compiler had the STORE verb which allowed
arbitrary values to be stored into the instruction
stream and was often used insert instructions
into the code stream.

For example:
GetMixInfo(a,b,c)= BEGIN UNSEGMENTED 00032000
BCT 0214; 00033000
BeginBCTParms 00034000
STORE(08) := @000000DB@; 00035000
STORE(06) := [a.NO]; 00036000
STORE(06) := [b.NO]; 00037000
STORE(06) := [c.NO]; 00038000
EndBCTParms; 00039000
END;#; 00040000

Stored the parameters for a branch communicate (trap to MCP) instruction.

DEFINE SPIO(iocb) = STORE(6) := @940000@;
STORE := [iocb.UN];#;
DEFINE HBR(label) = STORE(2) := @29@;
STORE := [label.NO];#;
DEFINE SST(area) = STORE(6) := @990001@;
STORE := [area.UA];#;
DEFINE WHR(bf, field) = STORE(4) := @6500@;
STORE(2) := bf;
STORE := [field.UN];#;

Defines macros to generate specific instructions (SPIO is Start Physical
I/O, HBR is Halt Branch, SST is System Status, WHR is Write Hardware Register).


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-04-16 16:21, wij wrote:

On Thu, 2026-04-16 at 13:10 +0000, Kenny McCormack wrote:

In article <1e4ef965d5ee27013e0abfd3c5dc18831400ad5f.camel@gmail.com>,
wijÿ <wyniijj5@gmail.com> wrote:
...

It seem you insist C and assembly have to be exactly what your bible says. >>> If so, I would say what C standard (I cannot read it) says is the meaning >>> of terminology of term in it, not intended to be anything used in any
other situation.

Keith is the king of this newsgroup.ÿ What he says, goes.
The way he defines words is the law, and all must fall in line with that.

Forget about that, fact first. There are LLM. This is not court.

As I know, comp.lang.c should be a forum for more general topics than lang.c.mod, comp.lang.c.std. And,ÿrefrain from telling what other should do, you are just another participant.

You probably have taken Kenny's words literally, missed his tone,
and thus misunderstood what he actually was intending to express.

Reread his post and allow the option that it was meant sarcastic.

Janis


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 16/04/2026 16:38, Scott Lurndal wrote:

antispam@fricas.org (Waldek Hebisch) writes:

David Brown <david.brown@hesbynett.no> wrote:

On 15/04/2026 18:58, wij wrote:

Assembly compiler (or language) can also do the same optimization.

No, assemblers cannot do that - if they did, they would not be
assemblers. An assembler directly translates your instructions from
mnemonic codes (assembly instructions) to binary opcodes. Some
assemblers might have pseudo-instructions that translate to more than
one binary opcode, but always in a specific defined pattern.

Well, as a program assembler is not a compiler. But people talk
about "assembly language" and you can have a compiler that
takes assembly language as an input. This was done by DEC
for VAX assembly. A guy created compilers for 360 assembly,
one targeting 386, another one targetimg Java. Such compilers
to be useful should do same optimization.

The C compiler in the GNU Compiler Collection provides
a mechanism to 'take assembly language as an input'
in the form of in-line assembler fragments. It's
useful in some limited cases (machine-level software like
kernels, boot loaders and the like).

Not really, no. gcc "asm" statements accept a kind of template language
and fills in certain types of parameters (used to pass register names, symbolic addresses, etc. to the assembly) then passes the rest of the
template string directly on to the generated assembly file. It does not interpret the assembly in any way, or do any kind of checking. gcc does
not take assembly language as an input any more than a typical printf statement takes English language as an input.

But gcc inline assembly is definitely useful at times - you are right there!


--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Thu, 16 Apr 2026 14:38:06 +0000, Scott Lurndal wrote:

antispam@fricas.org (Waldek Hebisch) writes:

David Brown <david.brown@hesbynett.no> wrote:

On 15/04/2026 18:58, wij wrote:

Assembly compiler (or language) can also do the same optimization.

No, assemblers cannot do that - if they did, they would not be
assemblers. An assembler directly translates your instructions from
mnemonic codes (assembly instructions) to binary opcodes. Some
assemblers might have pseudo-instructions that translate to more than
one binary opcode, but always in a specific defined pattern.

Well, as a program assembler is not a compiler. But people talk
about "assembly language" and you can have a compiler that
takes assembly language as an input. This was done by DEC
for VAX assembly. A guy created compilers for 360 assembly,
one targeting 386, another one targetimg Java. Such compilers
to be useful should do same optimization.

The C compiler in the GNU Compiler Collection provides
a mechanism to 'take assembly language as an input'
in the form of in-line assembler fragments. It's
useful in some limited cases (machine-level software like
kernels, boot loaders and the like).

I believe that the authors of GNU C latched on to an (at the
time) useful extension of the C language, originally implemented
in Ron Cain's "Small C Compiler for the 8080's" (Dr. Dobbs
Journal # 45, 1980) as the #asm/#endasm preprocessor directives.
Ron's K&R C subset compiler didn't compile to machine code;
instead, it compiled to CP/M 8080 assembler (CP/M came with
an 8080 assembler as it's only language tool), and so an
sourcecode assembly "passthrough" was easily implemented.

The Burroughs Large systems (B5500 and descendents) has
never had an assembler; all code is written in a flavor
of Algol (with special syntax extensions required for
the MCP and other privileged applications).

The Burroughs Medium systems COBOL68 compiler supported
the 'ENTER SYMBOLIC' statement, which was followed by
in-line assembler until the LEAVE SYMBOLIC statement.

The IBM language environments that I worked in all
supported static (and later, dynamic) linkage, and my
employer could afford a suite of IBM language tools.
IBMs language tools shared a common object interface,
so it was (relatively) easy to write the Assembly
parts in Assembler, and the HLL parts in the appropriate
HLL (ususally, for us, COBOL), and link them together
for execution.

Consequently, none of the high-level languages supported
an "assembly" escape (although COBOL provided extensions
for IBM DB2 relational database interaction).

[snip]

FWIW, I believe that the origins of C had much the same
philosophy: write parts in suitable languages, and link
them together prior to execution. K&R C had no reason
to support inline assembly (and, as far as I have read)
the authors studiously avoided that capability.

--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)