Janis Papanagnou <[email protected]> writes:
On 21.03.2025 00:10, Keith Thompson wrote:
bart <[email protected]> writes:
[...]
Look at this one for example:
typedef uint8_t byte; // from arduino.h
I can only one of reason this exists, which is that 'byte' is a far
nicer denotation.
I agree in this case. "byte" documents what the type is intended for.
I disagree on both above expressed opinions in more than one way.
Byte is a bad term to denote a quantity or an intention. Formerly
a "Byte" was used to carry characters; its size could be anything
from 5 to 9 bit. There was a reason why in international standards
documents there's the 'octet' introduced to unambiguously hint to
an 8-bit quantity. Neither is it good, as we see in practice, to
assume a 'byte' (whatever it actually is) to be able to carry a
character, not even 'char' or 'unsigned char' seem to be able to
accomplish that given the "wide character" types in the context of
Unicode (16 bit, 32 bit) characters and (variable-length) UTF-8
encodings.
"Byte" is a defined term in C. The definition is "addressable
unit of data storage large enough to hold any member of the basic
character set of the execution environment", but other parts of
the standard make it clear that sizeof yields a count of bytes,
that there are CHAR_BIT bits in a byte, that types char, unsigned
char, and signed char are all one byte in size, and that CHAR_BIT
is at least 8 but can be bigger. I'm aware of the history, but if
I defined a "byte" type in C that's what I would mean.
It is IMHO unfortunate that "bytes" and "characters" are conflated
in C. This was done before multi-byte or wide characters were a
thing, but we're stuck with it.
The definition above:
typedef uint8_t byte; // from arduino.h
is IMHO not ideal. Various language rules taken together imply
that uint8_t *either* is exactly one byte *or* does not exist (if CHAR_BIT>8), but unsigned char is directly specified to be exactly
one byte. But it's system-specific, so I wouldn't worry about it
or advocate changing it.
Personally, I think "typedef uint8_t byte;" /is/ ideal - and much better
than "typedef unsigned char byte;" would be. I say that as someone who
works in a field with bits and bytes more than ints and doubles.
Personally, I think [...]
Thus pretty much any programmer in the last 50 years sees "byte" as synonymous with 8-bit octet, including C programmers,
and for the last
30 years or so it has been the ISO standard definition of the term.
[...]
On 25.03.2025 10:38, David Brown wrote:
Personally, I think [...]
(I'll skip most of that in your post.)
Thus pretty much any programmer in the last 50 years sees "byte" as
synonymous with 8-bit octet, including C programmers,
Be careful if you are not speaking for yourself, and especially if
you extrapolate to such a lengthy period of time.
50 years ago was 1975 (and about the time I wrote my first programs).
And it was even some years later that I programmed on CDC 175 or 176,
a machine with a word length of 60 bit, 6 bit characters and Pascal's
'text' data type was a 'packed array [1..10] of character'. (Just to
give an example.) Computer scientists generally had a much broader
view back these days.
If you'd have said 40 years ago, about the time when MS DOS systems
got popular,
I'm asking because I was in my post already referring to international standards (ISO, CCITT/ITU-T, etc.) that have defined 'octet' for the
purpose of unambiguously identifying an 8 bit entity. The 'octet' went
into the ASN.1 protocol standard notation (that you will now also find
in IETF's RFC standards).
On 2025-03-25, David Brown <[email protected]> wrote:
Personally, I think "typedef uint8_t byte;" /is/ ideal - and much better
than "typedef unsigned char byte;" would be. I say that as someone who
works in a field with bits and bytes more than ints and doubles.
The problem is that uint8_t is not endowed with the special
aliasing rules for accessing objects of other types as arrays
of unsigned char. A type called byte is prone to precipitating
into those uses.
A platform like Arduino could assert that in their toolchain,
the type byte does have those properties (and then somehow ensure
that is true, in spite of it being uint8_t, like by patching
the compiler if they have to).
On 25/03/2025 18:18, Janis Papanagnou wrote:
If you'd have said 40 years ago, about the time when MS DOS systems
got popular,
1985? That's a bit late!
8-bit processors started around the mid-70s, pretty much 50 years ago.
I would guess more people started using those during the late 70s,
than were using those odd mainframes, since they
were so much more accessible.
You could literally buy a CPU from a corner electronics store.
(I believe the IBM 360 used 8-bit bytes from the 1960s.)
[...]
On 25.03.2025 19:50, bart wrote:
On 25/03/2025 18:18, Janis Papanagnou wrote:
If you'd have said 40 years ago, about the time when MS DOS systems
got popular,
1985? That's a bit late!
I was speaking about MS-DOS systems that got available where I live
around 1982.
Few people could afford to buy the IBM systems. But they
marked the line where these system got popular here. A non-significant
but noticeable distribution of these systems could be observed around 1984/1985. That's about when "common folks" started to "talk IT".
8-bit processors started around the mid-70s, pretty much 50 years ago.
One of the first systems I used (around 1978) was a Commodore PET 2001.
There were (very few) other folks that used the first Apple computers
(also very expensive equipment here). There was another (I forgot the
name; it ran the CPM OS) which was affordable, and a bit later came
the Amiga and the Atari.
One thing I was describing is the two groups; professionals and, say, "wannabes". While the first group had a complete view on the scenery
the latter group's (much more limited) view determined the perception.
David Brown <[email protected]> writes:
On 25/03/2025 17:31, Kaz Kylheku wrote:
On 2025-03-25, David Brown <[email protected]> wrote:
Personally, I think "typedef uint8_t byte;" /is/ ideal - and much better >>>> than "typedef unsigned char byte;" would be. I say that as someone who >>>> works in a field with bits and bytes more than ints and doubles.The problem is that uint8_t is not endowed with the special
aliasing rules for accessing objects of other types as arrays
of unsigned char. A type called byte is prone to precipitating
into those uses.
The minimum size for an "unsigned char" is 8 bits. There are no other
standard integer types that are unsigned, have no padding bits, and
can be 8 bits in size (except that plain "char" can be identical to
"unsigned char"). "uint8_t" is a typedef of an integer type that is
exactly 8 bits, with no padding. There can be no C implementation for
which "uint8_t" can exist, and for which "unsigned char" is not an
appropriate choice. No other standard integer types can possibly be
suitable (except perhaps "char").
So if "uint8_t" on an implementation is /not/ a typedef for unsigned
char, the implementation must be providing an extended integer type of
identical size and characteristics to "unsigned char". No known
implementation of C has, to my knowledge, ever had actual extended
integer types.
In order for a C implementation to provide a uint8_t type that does
not have the "magic" aliasing powers of character types (now called
"byte types" in C23), the implementation would have to provide an
extended integer type otherwise identical to "unsigned char" except
for its aliasing powers, and specifically use that for "uint8_t"
contrary to normal user expectations. I believe this is
hypothetically possible, but so unrealistic as to be ignorable.
However, if you or anyone else has reason to believe it /is/
realistic, I'd appreciate hearing about it.
A platform like Arduino could assert that in their toolchain,
the type byte does have those properties (and then somehow ensure
that is true, in spite of it being uint8_t, like by patching
the compiler if they have to).
"uint8_t" is a typedef - not its own integer type. If it is a typedef
of "unsigned char" (as it is for the AVR gcc port, used by the
Arduino), it inherits the magic aliasing powers of "unsigned char" -
typedef names an alias, not a new type.
If it requires that long a line of reasoning to prove that uint8_t is
*very probably* an appropriate byte type, why not just use unsigned
char, which is guaranteed to be an appropriate byte type?
If you like, you can add:
#if CHAR_BIT != 8
#error "Nope"
#endif
When I'm writing C, "byte" doesn't mean 8 bits. It means CHAR_BIT bits.
On 25.03.2025 10:38, David Brown wrote:
Personally, I think [...]
(I'll skip most of that in your post.)
Thus pretty much any programmer in the last 50 years sees "byte" as
synonymous with 8-bit octet, including C programmers,
Be careful if you are not speaking for yourself, and especially if
you extrapolate to such a lengthy period of time.
50 years ago was 1975 (and about the time I wrote my first programs).
And it was even some years later that I programmed on CDC 175 or 176,
a machine with a word length of 60 bit, 6 bit characters and Pascal's
'text' data type was a 'packed array [1..10] of character'. (Just to
give an example.) Computer scientists generally had a much broader
view back these days.
If you'd have said 40 years ago, about the time when MS DOS systems
got popular, I would have agreed about the prevalent opinion. OTOH,
with all this populism a lot of quality degradation entered the IT
scenery (at least, as far as my observation goes); things were not
taken as accurately as would have been appropriate.
and for the last
30 years or so it has been the ISO standard definition of the term.
I suppose you meant the "ISO _C_ standard definition"?
I'm asking because I was in my post already referring to international standards (ISO, CCITT/ITU-T, etc.) that have defined 'octet' for the
purpose of unambiguously identifying an 8 bit entity. The 'octet' went
into the ASN.1 protocol standard notation (that you will now also find
in IETF's RFC standards).
David Brown <[email protected]> writes:
[...]
Thus pretty much any programmer in the last 50 years sees "byte" as
synonymous with 8-bit octet, including C programmers, and for the last
30 years or so it has been the ISO standard definition of the
term.
What ISO standard definition are you referring to? The ISO C standard certainly doesn't define a "byte" to be 8 bits. I'd be surprised if any other ISO standard did so.
On 25.03.2025 19:50, bart wrote:
On 25/03/2025 18:18, Janis Papanagnou wrote:
If you'd have said 40 years ago, about the time when MS DOS systems
got popular,
1985? That's a bit late!
I was speaking about MS-DOS systems that got available where I live
around 1982. Few people could afford to buy the IBM systems. But they
marked the line where these system got popular here. A non-significant
but noticeable distribution of these systems could be observed around 1984/1985. That's about when "common folks" started to "talk IT".
8-bit processors started around the mid-70s, pretty much 50 years ago.
One of the first systems I used (around 1978) was a Commodore PET 2001.
There were (very few) other folks that used the first Apple computers
(also very expensive equipment here). There was another (I forgot the
name; it ran the CPM OS) which was affordable, and a bit later came
the Amiga and the Atari.
I would guess more people started using those during the late 70s,
The pervasion in society came much later! (It may have been different
where you live. But I'd be surprised if it would have been a completely different situation.)
In 1978 a Commodore Pet 2001 costs 2000 DM (I think it must have been
around 500 US$ back these days). Few people could afford to buy one.
And most people had no use for it anyway. Only nerds with sufficient
income could buy one to play with it.
But the fact that "octet" was a standardised term for 8 bits prior to
the standardisation of the term "byte", does not change the fact that
the term "byte" was standardised as 8 bits - in common computing usage
by at least 40 years ago (though I still think 50 years ago is
reasonable), and in official international standards by at least 30
years ago.
On 26/03/2025 10:10, David Brown wrote:
But the fact that "octet" was a standardised term for 8 bits prior to
the standardisation of the term "byte", does not change the fact that
the term "byte" was standardised as 8 bits - in common computing usage
by at least 40 years ago (though I still think 50 years ago is
reasonable), and in official international standards by at least 30
years ago.
I was taught - probably wrongly - that byte was a contraction of 'binary-eight'.
On 26/03/2025 12:02, Richard Harnden wrote:
On 26/03/2025 10:10, David Brown wrote:
But the fact that "octet" was a standardised term for 8 bits prior to
the standardisation of the term "byte", does not change the fact that
the term "byte" was standardised as 8 bits - in common computing
usage by at least 40 years ago (though I still think 50 years ago is
reasonable), and in official international standards by at least 30
years ago.
I was taught - probably wrongly - that byte was a contraction of
'binary-eight'.
As far as I know, it was just a re-spelling (to avoid mixups with "bit")
of the word "bite" that was used to indicate a small chunk of something.
Certainly the word was used before its size was fixed at 8 bits.
The word "bit", on the other hand, is often said to come from "binary
digit" or "binary information digit". Personally, I think it is a lot simpler - it's the smallest usable bit of information you can have.
Saying it is a "binary digit" just makes it clearer how big a bit you have.
On 26/03/2025 11:47, David Brown wrote:
On 26/03/2025 12:02, Richard Harnden wrote:
On 26/03/2025 10:10, David Brown wrote:
But the fact that "octet" was a standardised term for 8 bits prior
to the standardisation of the term "byte", does not change the fact
that the term "byte" was standardised as 8 bits - in common
computing usage by at least 40 years ago (though I still think 50
years ago is reasonable), and in official international standards by
at least 30 years ago.
I was taught - probably wrongly - that byte was a contraction of
'binary-eight'.
As far as I know, it was just a re-spelling (to avoid mixups with
"bit") of the word "bite" that was used to indicate a small chunk of
something. Certainly the word was used before its size was fixed at
8 bits.
The word "bit", on the other hand, is often said to come from "binary
digit" or "binary information digit". Personally, I think it is a lot
simpler - it's the smallest usable bit of information you can have.
Saying it is a "binary digit" just makes it clearer how big a bit you
have.
So where did a 'bit' being 1/8th of a dollar come from? (As in, two bits being 25 cents.) Maybe a coincidence?
On 25/03/2025 19:45, Janis Papanagnou wrote:
One thing I was describing is the two groups; professionals and, say,
"wannabes". While the first group had a complete view on the scenery
the latter group's (much more limited) view determined the perception.
I don't have time for such elitism.
In the UK at least, home computers were wildly popular from the start of
the 1980's, when they became much cheaper, had usable BASIC languages,
and a wide supply of games. DOS and CP/M systems were pretty much
business only - home computers hugely outnumbered such systems.
Virtually all home computers were 8-bit - though most users would have
little knowledge of that.
In 1978 a Commodore Pet 2001 costs 2000 DM (I think it must have been
around 500 US$ back these days). Few people could afford to buy one.
And most people had no use for it anyway. Only nerds with sufficient
income could buy one to play with it.
The Pet was early and expensive - my father had one at home in
connection with his job. (I never got to program it, but I was six at
the time.)
But the market exploded a few years after that with a wide
variety of home computers. By the mid eighties, a large proportion of households in the UK with teenage boys had a home computer of some sort.
On 25/03/2025 19:18, Janis Papanagnou wrote:
[...]
OK, let's say 40 years ago. But even by 1975, it was clear that 8-bit groupings were already dominant and other sizes were only going to see
usage in niche devices or for compatibility with existing older designs.
[...]
The word "bit", on the other hand, is often said to come from "binary
digit" or "binary information digit".
Personally, I think it is a lot
simpler - it's the smallest usable bit of information you can have.
Saying it is a "binary digit" just makes it clearer how big a bit you have.
On 26.03.2025 11:29, David Brown wrote:
In the UK at least, home computers were wildly popular from the start of
the 1980's, when they became much cheaper, had usable BASIC languages,
and a wide supply of games. DOS and CP/M systems were pretty much
business only - home computers hugely outnumbered such systems.
Virtually all home computers were 8-bit - though most users would have
little knowledge of that.
I basically agree. Only that those geeks and nerds who privately
bought such computer systems here were mostly informed about the
technical details.
(Ah, now I remember the system name I forgot in a previous post;
it was a "Schneider" PC with CPM. And some toy called Sinclair ZX
or so.)
On 26/03/2025 15:08, Janis Papanagnou wrote:
On 26.03.2025 11:29, David Brown wrote:
In the UK at least, home computers were wildly popular from the start of >>> the 1980's, when they became much cheaper, had usable BASIC languages,
and a wide supply of games. DOS and CP/M systems were pretty much
business only - home computers hugely outnumbered such systems.
Virtually all home computers were 8-bit - though most users would have
little knowledge of that.
I basically agree. Only that those geeks and nerds who privately
bought such computer systems here were mostly informed about the
technical details.
That would, I think, apply to the technically-minded adults who bought
early computers themselves - rather than the kids whose parents bought
them.
(Ah, now I remember the system name I forgot in a previous post;
it was a "Schneider" PC with CPM. And some toy called Sinclair ZX
or so.)
The Sinclair computers (ZX81, ZX Spectrum) launched a generation of programmers and technically-minded kids in the UK - it was much more
than a toy. I learned machine code programming on a Spectrum (along
with a BBC Micro), as well as some Forth, C, Pascal and Logo, in
addition to the built-in BASIC.
On 26/03/2025 10:10, David Brown wrote:
But the fact that "octet" was a standardised term for 8 bits prior to
the standardisation of the term "byte", does not change the fact that
the term "byte" was standardised as 8 bits - in common computing usage
by at least 40 years ago (though I still think 50 years ago is
reasonable), and in official international standards by at least 30
years ago.
I was taught - probably wrongly - that byte was a contraction of 'binary-eight'.
On 26.03.2025 17:50, David Brown wrote:
On 26/03/2025 15:08, Janis Papanagnou wrote:
On 26.03.2025 11:29, David Brown wrote:
In the UK at least, home computers were wildly popular from the start of >>>> the 1980's, when they became much cheaper, had usable BASIC languages, >>>> and a wide supply of games. DOS and CP/M systems were pretty much
business only - home computers hugely outnumbered such systems.
Virtually all home computers were 8-bit - though most users would have >>>> little knowledge of that.
I basically agree. Only that those geeks and nerds who privately
bought such computer systems here were mostly informed about the
technical details.
That would, I think, apply to the technically-minded adults who bought
early computers themselves - rather than the kids whose parents bought
them.
Actually, as to my observations, the "parents" were a negligible
community regarding use of computers, it were mostly folks of
ages 16-30 (back these days and in our country). Nerds or geeks,
as to a characterization. The social situation is very different
nowadays.
(Ah, now I remember the system name I forgot in a previous post;
it was a "Schneider" PC with CPM. And some toy called Sinclair ZX
or so.)
The Sinclair computers (ZX81, ZX Spectrum) launched a generation of
programmers and technically-minded kids in the UK - it was much more
than a toy. I learned machine code programming on a Spectrum (along
with a BBC Micro), as well as some Forth, C, Pascal and Logo, in
addition to the built-in BASIC.
Oh, please, don't get me wrong. Of course you could do a lot of
geeky stuff with those devices and learn a lot about that (then
"new") technology. The "toy" character as I named it I perceived
from the lousy hardware (membrane keyboard, TV as display, etc. -
unless I am confusing things) and also what seems to have been
mostly done with those devices.
On the minus side, if you wanted to learn about IT or CS - we've
got a lot of bad paragons from many of these primitive systems;
OSes like DOS, languages like BASIC, primitive CPU architectures,
and whatnot. (YMMV)
On 26/03/2025 18:09, Janis Papanagnou wrote:
8-bit architectures were fine, just a bit short of registers and with >limitation instruction sets. But that is to be expected with only 27,000 >transistors on a chip or whatever it was for Z80.
(BTW, have a go at emulating such a processor in sofware; tell me in 3
months how you got on.)
On 26.03.2025 17:50, David Brown wrote:
On 26/03/2025 15:08, Janis Papanagnou wrote:
On 26.03.2025 11:29, David Brown wrote:
In the UK at least, home computers were wildly popular from the start of >>>> the 1980's, when they became much cheaper, had usable BASIC languages, >>>> and a wide supply of games. DOS and CP/M systems were pretty much
business only - home computers hugely outnumbered such systems.
Virtually all home computers were 8-bit - though most users would have >>>> little knowledge of that.
I basically agree. Only that those geeks and nerds who privately
bought such computer systems here were mostly informed about the
technical details.
That would, I think, apply to the technically-minded adults who bought
early computers themselves - rather than the kids whose parents bought
them.
Actually, as to my observations, the "parents" were a negligible
community regarding use of computers, it were mostly folks of
ages 16-30 (back these days and in our country). Nerds or geeks,
as to a characterization. The social situation is very different
nowadays.
(Ah, now I remember the system name I forgot in a previous post;
it was a "Schneider" PC with CPM. And some toy called Sinclair ZX
or so.)
The Sinclair computers (ZX81, ZX Spectrum) launched a generation of
programmers and technically-minded kids in the UK - it was much more
than a toy. I learned machine code programming on a Spectrum (along
with a BBC Micro), as well as some Forth, C, Pascal and Logo, in
addition to the built-in BASIC.
Oh, please, don't get me wrong. Of course you could do a lot of
geeky stuff with those devices and learn a lot about that (then
"new") technology. The "toy" character as I named it I perceived
from the lousy hardware (membrane keyboard, TV as display, etc. -
unless I am confusing things) and also what seems to have been
mostly done with those devices.
On the minus side, if you wanted to learn about IT or CS - we've
got a lot of bad paragons from many of these primitive systems;
OSes like DOS,
languages like BASIC
, primitive CPU architectures,
(YMMV)
bart <[email protected]> writes:
On 26/03/2025 18:09, Janis Papanagnou wrote:
8-bit architectures were fine, just a bit short of registers and with
limitation instruction sets. But that is to be expected with only 27,000
transistors on a chip or whatever it was for Z80.
(BTW, have a go at emulating such a processor in sofware; tell me in 3
months how you got on.)
Emulating processors in software is my day job. It's gone
quite well; the count is up to 8 or nine at this point,
including mainframe, cortex-M and ARMv8. The last one
is described by about 20,000 pages of documentation,
so emulation isn't simple.
On 26/03/2025 18:09, Janis Papanagnou wrote:
, primitive CPU architectures,
8-bit architectures were fine, just a bit short of registers and with limitation instruction sets. But that is to be expected with only 27,000 transistors on a chip or whatever it was for Z80.
(BTW, have a go at emulating such a processor in sofware; tell me in 3
months how you got on.)
But also at that time - early 80s when Spectrums etc were popular -
there were some wonderful new 16/32-bit processors such as 68000,
Z8000/0 and NS32032, of which only the first survived.
bart <[email protected]> wrote:
On 26/03/2025 18:09, Janis Papanagnou wrote:
, primitive CPU architectures,
8-bit architectures were fine, just a bit short of registers and with
limitation instruction sets. But that is to be expected with only 27,000
transistors on a chip or whatever it was for Z80.
All sources that I found say that Z80 is about 8000 transistors.
You probably took number from 8086 which was climed to have 27000
transitors.
Z80 (like earlier 8080) in "general" instructions required
accumulator as one of arguments, that severly limited utility
of registers.
(BTW, have a go at emulating such a processor in sofware; tell me in 3
months how you got on.)
Lone processor is not very interesting. I do not think coding
simple emulator would take a lot of time. Z80 instruction set
is a bit bulky, due to prefixed instructions, but decode could
be done quite naively using 5 tables with 256 positions each
(or a bit smarter using 3 tables)
Looking at short description of Z8000, it does not look nice:
it has ugly "segmentation" scheme to address more than 64kB
of memory.
On 26/03/2025 18:09, Janis Papanagnou wrote:[...]
Oh, please, don't get me wrong. Of course you could do a lot of
geeky stuff with those devices and learn a lot about that (then
"new") technology. The "toy" character as I named it I perceived
from the lousy hardware (membrane keyboard, TV as display, etc. -
unless I am confusing things) and also what seems to have been
mostly done with those devices.
On the minus side, if you wanted to learn about IT or CS - we've
Few played with this stuff because they wanted to learn CS. They wanted
to do interesting fun things.
Some commercial products were low quality because they had to be done
for a price. I think the ZX80 was £100, at a time when my company
produced a business computer, also Z80-based, for £1300. (One client
used one of our machines to more easily develop Spectrum programs.)
My own first machine was build from discrete chips, and the software had
to be developed from *nothing* (actually, from keying in binary code
using home-made switches). There was little scope for niceties.
The first apps with my crude languages revolved around vector graphics,
image processing, and frame-grabbing, *after* having to develop the assembler, editor, compiler and libraries needed to make it possible.
That was an incredible learning experience, which helped me get that job
with hardware, and formed my attitutes towards traditional tools that everybody is apparently still stuck with.
got a lot of bad paragons from many of these primitive systems;
OSes like DOS,
I had no interest whatsover in operating systems. I did fine without one
to start with, while CP/M (our rip-off of it) and DOS provided a file
system and a way to launch programs; what else was there?
languages like BASIC
What language would you have advocated that could fit into a few KB, and
that could run without a proper file system?
, primitive CPU architectures,
8-bit architectures were fine, just a bit short of registers and with limitation instruction sets. But that is to be expected with only 27,000 transistors on a chip or whatever it was for Z80.
(BTW, have a go at emulating such a processor in sofware; tell me in 3
months how you got on.)
But also at that time - early 80s when Spectrums etc were popular -
there were some wonderful new 16/32-bit processors such as 68000,
Z8000/0 and NS32032, of which only the first survived.
Their architecture is not that different from current machines.
(YMMV)
Yeah.
On 27/03/2025 01:10, Waldek Hebisch wrote:
bart <[email protected]> wrote:
On 26/03/2025 18:09, Janis Papanagnou wrote:
, primitive CPU architectures,
8-bit architectures were fine, just a bit short of registers and with
limitation instruction sets. But that is to be expected with only 27,000 >>> transistors on a chip or whatever it was for Z80.
All sources that I found say that Z80 is about 8000 transistors.
You probably took number from 8086 which was climed to have 27000
transitors.
OK, then with 8000 it makes the capabilities even more remarkable.
Current processors have billions of transistors.
On 27.03.2025 00:21, bart wrote:
Some commercial products were low quality because they had to be done
for a price. I think the ZX80 was £100, at a time when my company
produced a business computer, also Z80-based, for £1300. (One client
used one of our machines to more easily develop Spectrum programs.)
I'm speaking about all that inferior systems that had a comparably
high price without a matching quality. And about years and years
passing without vendors of such products changing that situation.
What language would you have advocated that could fit into a few KB, and
that could run without a proper file system?
The first that comes to mind was (for example) Pascal. It actually
became available on several platforms. But it was not comparable
to the omnipresent [lousy] BASIC that was inherent part of the OS
in the ROM. (Well, or on a 8" floppy; e.g. in case of the Olivetti
P6060.) There were other languages available; someone (maybe David)
mentioned some upthread. Myself I bought a Simula compiler for my
Atari ST. Simula is a powerful and comparably huge language, so your
"few KB" excuse is not convincing.
I think it was a professor at the university who meant that anyone
who started with BASIC would be incapable of ever doing real CS. -
This is of course nonsense! (And such arguments say more about the
person formulating such non-arguments. - I recall a similar nonsense mentioned here by someone some months ago concerning OO and Simula
and all other OO languages that took their OO concepts from Simula.)
The point with BASIC is that if all you know is BASIC without knowing anything else you probably won't be able to understand the problems
with it. I know you have a broader language repertoire, so I presume
you know BASIC's deficiencies (or at least the deficiencies of those
BASIC dialects that were around until around 1980).
In the past I had implemented an emulator for the SC 61860; if that
helps you in any way with your argument please let me know.
But also at that time - early 80s when Spectrums etc were popular -
there were some wonderful new 16/32-bit processors such as 68000,
Z8000/0 and NS32032, of which only the first survived.
I've had contact with a couple CPUs back these days; 6502 (6510),
68000, 8080 (Z80), another Intel thing where I forgot the number,
SC 61860, TMS 320 C25. And I read about (but not programmed) a
couple more (the SPARC, one from National Semiconductors) where
I forgot the model numbers.
The 68000, specifically, is a great example for an inferior CPU
architecture. (Your mileage obviously varies if you think it was
even "wonderful".)
CPU architectures that I found to be more interesting were SPARC,
the National Semiconductor thing (NS 32016 maybe? nor sure), and
the TMS DSP (where I spent quite some time with), for example.
But that all was long ago and is meaningless today.
It's interesting to still see advocates of inferior IT justifying
bad paragons, though.
On 27/03/2025 02:33, bart wrote:
On 27/03/2025 01:10, Waldek Hebisch wrote:
bart <[email protected]> wrote:
On 26/03/2025 18:09, Janis Papanagnou wrote:
, primitive CPU architectures,
8-bit architectures were fine, just a bit short of registers and with
limitation instruction sets. But that is to be expected with only 27,000 >>>> transistors on a chip or whatever it was for Z80.
All sources that I found say that Z80 is about 8000 transistors.
You probably took number from 8086 which was climed to have 27000
transitors.
OK, then with 8000 it makes the capabilities even more remarkable.
Current processors have billions of transistors.
Most of the bulk of current processors are arrays or repetitions -
caches, arrays of registers, etc. The "interesting" bits are orders of >magnitude smaller than the chip as a whole.
But I am always impressed by how much older designs managed to do with
so few transistors - even if Wikipedia says 8500 transistors rather than >8000, and even though the logic families of such systems used fewer >transistors per gate than modern CMOS.
On 26/03/2025 23:51, Scott Lurndal wrote:
bart <[email protected]> writes:
On 26/03/2025 18:09, Janis Papanagnou wrote:
8-bit architectures were fine, just a bit short of registers and with
limitation instruction sets. But that is to be expected with only 27,000 >>> transistors on a chip or whatever it was for Z80.
(BTW, have a go at emulating such a processor in sofware; tell me in 3
months how you got on.)
Emulating processors in software is my day job. It's gone
quite well; the count is up to 8 or nine at this point,
including mainframe, cortex-M and ARMv8. The last one
is described by about 20,000 pages of documentation,
so emulation isn't simple.
This my point. I've seen a Z80 emulator in C which was 4000 lines of
tight code, and that is for something considered simple.
(I can't remember if it was emulated at the granularity of clock cycles
or coarser. My own attempt worked an instruction at time, but I got up
to 12 opcodes before it was put aside, for other reasons.)
bart <[email protected]> wrote:
On 26/03/2025 18:09, Janis Papanagnou wrote:
, primitive CPU architectures,
8-bit architectures were fine, just a bit short of registers and with
limitation instruction sets. But that is to be expected with only 27,000
transistors on a chip or whatever it was for Z80.
All sources that I found say that Z80 is about 8000 transistors.
You probably took number from 8086 which was climed to have 27000
transitors.
Z80 (like earlier 8080) in "general" instructions required
accumulator as one of arguments, that severly limited utility
of registers.
(BTW, have a go at emulating such a processor in sofware; tell me in 3
months how you got on.)
Lone processor is not very interesting. I do not think coding
simple emulator would take a lot of time. Z80 instruction set
is a bit bulky, due to prefixed instructions, but decode could
be done quite naively using 5 tables with 256 positions each
(or a bit smarter using 3 tables). One needs hundreds of
routines to implement all instructions, but large part is reasonably
regular, so could be mechanically generated from small number
of templates. Code implementing less regular instructions
would take some time to write, but 3 months look like quite
generous estimate.
On 27.03.2025 00:21, bart wrote:
On 26/03/2025 18:09, Janis Papanagnou wrote:[...]
I had no interest whatsover in operating systems. I did fine without one
to start with, while CP/M (our rip-off of it) and DOS provided a file
system and a way to launch programs; what else was there?
languages like BASIC
What language would you have advocated that could fit into a few KB, and
that could run without a proper file system?
The first that comes to mind was (for example) Pascal. It actually
became available on several platforms. But it was not comparable
to the omnipresent [lousy] BASIC that was inherent part of the OS
in the ROM. (Well, or on a 8" floppy; e.g. in case of the Olivetti
P6060.) There were other languages available; someone (maybe David)
mentioned some upthread. Myself I bought a Simula compiler for my
Atari ST. Simula is a powerful and comparably huge language, so your
"few KB" excuse is not convincing.
I think it was a professor at the university who meant that anyone
who started with BASIC would be incapable of ever doing real CS.
This is of course nonsense! (And such arguments say more about the
person formulating such non-arguments. - I recall a similar nonsense mentioned here by someone some months ago concerning OO and Simula
and all other OO languages that took their OO concepts from Simula.)
The point with BASIC is that if all you know is BASIC without knowing anything else you probably won't be able to understand the problems
with it. I know you have a broader language repertoire, so I presume
you know BASIC's deficiencies (or at least the deficiencies of those
BASIC dialects that were around until around 1980).
But also at that time - early 80s when Spectrums etc were popular -
there were some wonderful new 16/32-bit processors such as 68000,
Z8000/0 and NS32032, of which only the first survived.
I've had contact with a couple CPUs back these days; 6502 (6510),
68000, 8080 (Z80), another Intel thing where I forgot the number,
SC 61860, TMS 320 C25. And I read about (but not programmed) a
couple more (the SPARC, one from National Semiconductors) where
I forgot the model numbers.
The 68000, specifically, is a great example for an inferior CPU
architecture. (Your mileage obviously varies if you think it was
even "wonderful".)
CPU architectures that I found to be more interesting were SPARC,
the National Semiconductor thing (NS 32016 maybe? nor sure), and
the TMS DSP (where I spent quite some time with), for example.
But that all was long ago and is meaningless today. Personally
I've occasionally programmed in assembler around 1980-1990, and
you can imagine that I don't care much about that topic anymore.
Their architecture is not that different from current machines.
That would be bad news. And I have my doubts that this is true.
(But as said, I don't care much anymore.)
It's interesting to still see advocates of inferior IT justifying
bad paragons, though. The situation has not changed. - Have fun!
On 27/03/2025 02:24, Janis Papanagnou wrote:
On 27.03.2025 00:21, bart wrote:
Some commercial products were low quality because they had to be done
for a price. I think the ZX80 was £100, at a time when my company
produced a business computer, also Z80-based, for £1300. (One client
used one of our machines to more easily develop Spectrum programs.)
I'm speaking about all that inferior systems that had a comparably
high price without a matching quality. And about years and years
passing without vendors of such products changing that situation.
I guess ... you're talking about either the IBM PC hardware or MS
software, or both? (Although PCs weren't expensive.)
On 27/03/2025 02:24, Janis Papanagnou wrote:
I'm speaking about all that inferior systems that had a comparably
high price without a matching quality. And about years and years
passing without vendors of such products changing that situation.
I guess ... you're talking about either the IBM PC hardware or MS
software, or both? (Although PCs weren't expensive.)
[ memory demands ]
Also, by a 'few KB' I meant single figures, like 2-8KB for the code,
plus RAM. That Atari seems to have a bit more available.
I've never used Basic. But it is one language I admire, even if it is
crude:
10 let a=0
20 let a=a+1
30 if a<1000000 then 20
40 print a
In the past I had implemented an emulator for the SC 61860; if that
helps you in any way with your argument please let me know.
The argument is that even such an apparently simple processor was not as 'primitive' as you seemed to think.
But also at that time - early 80s when Spectrums etc were popular -
there were some wonderful new 16/32-bit processors such as 68000,
Z8000/0 and NS32032, of which only the first survived.
I've had contact with a couple CPUs back these days; 6502 (6510),
68000, 8080 (Z80), another Intel thing where I forgot the number,
SC 61860, TMS 320 C25. And I read about (but not programmed) a
couple more (the SPARC, one from National Semiconductors) where
I forgot the model numbers.
The 68000, specifically, is a great example for an inferior CPU
architecture. (Your mileage obviously varies if you think it was
even "wonderful".)
OK, so what's wrong with it then? (It seemed to be adequate for that
Atari!)
[...]
But that all was long ago and is meaningless today.
I find I can learn a lot from how simple things were that long ago. The
early 80s was the golden age for that, getting away from mainframes and complex OSes, to much more informal systems. Now it's worse than ever.
It's interesting to still see advocates of inferior IT justifying
bad paragons, though.
So you have strong opinions about languages and machine architectures
and IT (whatever that is exactly).
I also have strong opinions about inferior languages like C and a few
other things. They are not that welcome in a forum like this. But I am
at least in the same field: I code at the lower level and also develop a parallel systems language.
The question is, what are /you/ doing here with all your lofty ideals
and sneering at everyone who isn't an academic or a 'professional'? I'm surprised you would even deign to look at a language like C.
On 27/03/2025 03:24, Janis Papanagnou wrote:
On 27.03.2025 00:21, bart wrote:
On 26/03/2025 18:09, Janis Papanagnou wrote:[...]
Many of the BASIC's on home computers were quite sophisticated - the BBC Micro (and later Archimedes) versions were famously advanced. Of course versions for things like the ZX80 - with 4 KB rom, and 1 KB ram (for
screen memory, OS data, interpreter data, BASIC program, and BASIC data)
were very limited.
Pascal would have been hopeless on such systems. A compiled - or even byte-compiled (such as P-code) - language would be totally out of the question. A minimal Pascal implementation, such as existed for the BBC Micros and the ZX Spectrum, needed more in the range of 16 K rom /
program and the same again of ram for source code, compiled /
byte-compiled code, and program data.
Remember, these systems did not have the resources you are talking
about. The Atari ST was a monster compared to the popular home
computers - 512 KB ram on the cheapest version, compared to more typical
16 KB - 32 KB ranges. And it had a price to match, way out of reach of
most home users.
[...]
I think it was a professor at the university who meant that anyone
who started with BASIC would be incapable of ever doing real CS.
It was Dijkstra who said that. As usual, his comments were
entertainingly exaggerated when made, and then taken out of context.
[...]
The point with BASIC is that if all you know is BASIC without knowing
anything else you probably won't be able to understand the problems
with it. I know you have a broader language repertoire, so I presume
you know BASIC's deficiencies (or at least the deficiencies of those
BASIC dialects that were around until around 1980).
That was not Dijstra's point at all - it was the "trial and error"
attitude to programming that you got from interpreted languages that he disliked.
However, your point /is/ still valid - people who are only
familiar with one programming language will have difficulty
understanding its limitations or seeing the benefits of other languages,
and tend to look at problems from a perspective limited by their own language.
[...]
The 68000, specifically, is a great example for an inferior CPU
architecture. (Your mileage obviously varies if you think it was
even "wonderful".)
What do you think is "inferior" about the 68k architecture? At the
time, the main business-world competitor, the 8086, was 8-bit with some 16-bit features, and built with a view towards backwards compatibility
rather than the future. The 68k had a 32-bit ISA with a 16-bit ALU -
looking towards the 32-bit future while accepting that it had to be cost-effective.
[...]
SPARC certainly had some interesting features and concepts. (I never
used it, but read a fair bit about it, and briefly used the Altera NIOS
soft core that had some similarities.) The TMS320C24x DSPs I used were utterly horrible.
[...]
There are plenty of things I find disappointingly similar between most
cpu architectures. It's hard for novel ideas to break through.
Part of
the blame for that, of course, is the success of C - a cpu design tends
to be successful if and only if it is efficient for the C model of programming, other than for a few specialised areas (like graphics work
or some highly SIMD-friendly algorithms). I'd like to see cpu designs
with multiple stacks, multiple register banks for fast task switching, hardware support for multi-tasking, locks, atomic accesses,
transactional memory, CSP-style message passing, memory allocation,
buffer management, etc. There are countless bits and pieces that could
make processors much faster and much more secure for a lot of work.
The XMOS devices are one of the few architectures to come up with really
new ideas and have some market success.
On 27.03.2025 12:14, bart wrote:
On 27/03/2025 02:24, Janis Papanagnou wrote:
Also, by a 'few KB' I meant single figures, like 2-8KB for the code,
plus RAM. That Atari seems to have a bit more available.
Yes, I was comparing it with the "standard" IBM PC (which had 640 kB)
and the Atari ST had first (I think) 500 kB (mine, a later version,
had 1 MB).
You are right to point out that some BASIC interpreters were provided
in a ROM. I don't recall the ROM sizes of all the PCs I used back then,
but I remember the Sharp PC 1401 pocket calculator that had 40 kB ROM
for the OS with BASIC.
I've never used Basic. But it is one language I admire, even if it is
crude:
10 let a=0
20 let a=a+1
30 if a<1000000 then 20
40 print a
Okay, you "admire" BASIC (and you found the 68000 CPU "wonderful");
that tells a lot about your background and expertise.
Try for a moment to understand that the quality of a CPU architecture is
not (for assembler programmers) something measured in transistors.
There's huge differences in processor _architectures_, though...
But also at that time - early 80s when Spectrums etc were popular -
there were some wonderful new 16/32-bit processors such as 68000,
Z8000/0 and NS32032, of which only the first survived.
If you mention 68000 and NS32032 playing in the same architectural
league then it's hard for me to consider you a serious discussion
partner.
On 27.03.2025 15:04, David Brown wrote:
On 27/03/2025 03:24, Janis Papanagnou wrote:
On 27.03.2025 00:21, bart wrote:
On 26/03/2025 18:09, Janis Papanagnou wrote:[...]
Many of the BASIC's on home computers were quite sophisticated - the BBC
Micro (and later Archimedes) versions were famously advanced. Of course
versions for things like the ZX80 - with 4 KB rom, and 1 KB ram (for
screen memory, OS data, interpreter data, BASIC program, and BASIC data)
were very limited.
I've programmed with a couple BASIC dialects back these days; besides
the mainframe thing; Olivetti, Wang, Commodore, Sharp. As seen from a
big picture, they all were basically the same crude thing. Only few
years later; Algol 68, Pascal, Simula, C, Fortran (half a step back),
C++, Java, and so on. Each of these languages was a progress compared
to BASIC (even Fortran, that I disliked as well).
Pascal would have been hopeless on such systems. A compiled - or even
byte-compiled (such as P-code) - language would be totally out of the
question. A minimal Pascal implementation, such as existed for the BBC
Micros and the ZX Spectrum, needed more in the range of 16 K rom /
program and the same again of ram for source code, compiled /
byte-compiled code, and program data.
I seem to recall that there were Pascal compilers available for a
couple of those old PC systems.
Anyway, I perceived the use of anything else than BASIC a challenge
on such systems; it seemed they were designed to just provide BASIC.
[...]
I think it was a professor at the university who meant that anyone
who started with BASIC would be incapable of ever doing real CS.
It was Dijkstra who said that. As usual, his comments were
entertainingly exaggerated when made, and then taken out of context.
No, I meant another professor whose lectures I attended at our
University. - It could of course be that he was just citing Dijkstra,
but he didn't sound as if he did; it was certainly his strong opinion.
[...]
The point with BASIC is that if all you know is BASIC without knowing
anything else you probably won't be able to understand the problems
with it. I know you have a broader language repertoire, so I presume
you know BASIC's deficiencies (or at least the deficiencies of those
BASIC dialects that were around until around 1980).
That was not Dijstra's point at all - it was the "trial and error"
attitude to programming that you got from interpreted languages that he
disliked.
As said, I wasn't attributing that to Dijkstra but a local professor.
And the argument was not about interpreters but more about lacking structuring features, hard coded line numbers, gotos, and a lot more
the like.
The 68000, specifically, is a great example for an inferior CPU
architecture. (Your mileage obviously varies if you think it was
even "wonderful".)
What do you think is "inferior" about the 68k architecture? At the
time, the main business-world competitor, the 8086, was 8-bit with some
16-bit features, and built with a view towards backwards compatibility
rather than the future. The 68k had a 32-bit ISA with a 16-bit ALU -
looking towards the 32-bit future while accepting that it had to be
cost-effective.
I wouldn't compare it to the x86 series - my opinion on that is not
much different to the 68k.
Have a look at the NS 32016/32 processors
(around 1979/1984). If you know the 68k but not the NS 32xxx you may
want to have a look into, e.g., "1986_National_NS32000_Databook.pdf"
(that you will find online).
[...]
SPARC certainly had some interesting features and concepts. (I never
used it, but read a fair bit about it, and briefly used the Altera NIOS
soft core that had some similarities.) The TMS320C24x DSPs I used were
utterly horrible.
I used it for the implementation of a channel encoding system, a
typical "signal processing" application; it was great. Imagining
I would have to use any other processor I already knew these days
(65xx, 68k, x86)... - that would have been really annoying.
[...]
There are plenty of things I find disappointingly similar between most
cpu architectures. It's hard for novel ideas to break through.
But there were ideas! But not only the interesting ideas (like the
frame shift on the stack [SPARC]; one detail I memorized) should have
been considered,
also (e.g.) support of addressing data structures as
known from (back then) contemporary languages; the NS 32xxx supported
that for example.
And these ideas were already old; see for example
Seegmüller: Einführung in die Systemprogrammierung (1974)
(And I would be surprised if he'd been the first who described that.)
But yes, the "break through" factors (e.g. the market factors) were
an issue.
Part of
the blame for that, of course, is the success of C - a cpu design tends
to be successful if and only if it is efficient for the C model of
programming, other than for a few specialised areas (like graphics work
or some highly SIMD-friendly algorithms). I'd like to see cpu designs
with multiple stacks, multiple register banks for fast task switching,
hardware support for multi-tasking, locks, atomic accesses,
transactional memory, CSP-style message passing, memory allocation,
buffer management, etc. There are countless bits and pieces that could
make processors much faster and much more secure for a lot of work.
The XMOS devices are one of the few architectures to come up with really
new ideas and have some market success.
For a long time now I'm not up to date any more with CPUs and their architectural differences.
[...]
[ NS32032 ]
Indeed. After all, the 68k was one of the most successful ISAs ever,
and the x86 "won" for economic reasons, not technical reasons. The
NS32000, on the other hand, is known only to a few nerds. [...]
I used it for the implementation of a channel encoding system, a
typical "signal processing" application; it was great. Imagining
I would have to use any other processor I already knew these days
(65xx, 68k, x86)... - that would have been really annoying.
There's no doubt that the TMS320 devices can be used to do many types
of DSP-style operations very efficiently. That's not the point -
that does not stop it from being horrible to work with. (It is also
fair to characterise it as an "interesting" architecture - that is
also not at odds with being horrible to use.)
On 28.03.2025 10:13, David Brown wrote:
[...]
David, you are not writing anything here that wasn't already addressed
by me or others before, so we can skip that. (And possibly agree to disagree.)
[ NS32032 ]
Indeed. After all, the 68k was one of the most successful ISAs ever,
and the x86 "won" for economic reasons, not technical reasons. The
NS32000, on the other hand, is known only to a few nerds. [...]
Given that it did not "survive" in the first place I was astonished
that when I spoke with IT professionals in the past it was mentioned
as outstanding (compared to a lot of other alternatives these days).
I was also astonished that bart had it in his short-list.
On 28/03/2025 02:59, Janis Papanagnou wrote:
Have a look at the NS 32016/32 processors
(around 1979/1984). If you know the 68k but not the NS 32xxx you may
want to have a look into, e.g., "1986_National_NS32000_Databook.pdf"
(that you will find online).
I had a look, to augment the little I knew of the NS30000 ISA. It is
very similar to the 68k in many ways. I think you'd have to dig into
fine detail to see real differences.
So, again, what do /you/ think is "inferior" about the 68k architecture?
Either I'm missing something, or you are missing something.
On 28.03.2025 10:13, David Brown wrote:
[...]
David, you are not writing anything here that wasn't already addressed
by me or others before, so we can skip that. (And possibly agree to disagree.)
[ NS32032 ]
Indeed. After all, the 68k was one of the most successful ISAs
ever, and the x86 "won" for economic reasons, not technical
reasons. The NS32000, on the other hand, is known only to a few
nerds. [...]
Given that it did not "survive" in the first place I was astonished
that when I spoke with IT professionals in the past it was mentioned
as outstanding (compared to a lot of other alternatives these days).
I was also astonished that bart had it in his short-list. So I'm not
inclined to accept your words that it's "known only to a few nerds".
(It's not necessarily the best technologies that "survive".) YMMV.
Janis
On 28/03/2025 10:03, David Brown wrote:
On 28/03/2025 02:59, Janis Papanagnou wrote:
Have a look at the NS 32016/32 processors
(around 1979/1984). If you know the 68k but not the NS 32xxx you may
want to have a look into, e.g., "1986_National_NS32000_Databook.pdf"
(that you will find online).
I had a look, to augment the little I knew of the NS30000 ISA. It is
very similar to the 68k in many ways. I think you'd have to dig into
fine detail to see real differences.
So, again, what do /you/ think is "inferior" about the 68k
architecture? Either I'm missing something, or you are missing
something.
I suspect the problem with the 68000 was that it was available to
'ordinary' people.
The NS device was more exclusive.
Similar with BASIC.
A one-off machine based on NS32032 and only running Simula would have
been ideal!
On 28/03/2025 02:59, Janis Papanagnou wrote:
Yes, BASIC was crude and limited - /all/ programming languages of that
era were crude and limited by today's standards, because /all/ computers
were crude and limited.
BASIC was perhaps more crude and limited than
others of the time, because it was used primarily on computers that were
more crude and limited.
[...]
I think it was a professor at the university who meant that anyone
who started with BASIC would be incapable of ever doing real CS.
It was Dijkstra who said that. As usual, his comments were
entertainingly exaggerated when made, and then taken out of context.
No, I meant another professor whose lectures I attended at our
University. - It could of course be that he was just citing Dijkstra,
but he didn't sound as if he did; it was certainly his strong opinion.
You can be very confident that he was citing, or paraphrasing, Dijkstra.
As said, I wasn't attributing that to Dijkstra but a local professor.
And the argument was not about interpreters but more about lacking
structuring features, hard coded line numbers, gotos, and a lot more
the like.
That is like criticising the Romans for using chariots instead of cars.
It is just prejudice and ignorance.
Later languages were able to have better structuring, and didn't need
line numbers, because the systems they were designed for were faster,
and had text editors.
And later BASICs had more structure, and dispensed with the need for
line numbers. With BBC BASIC, for example, you very rarely referred to
line numbers at all, and code was well structured (albeit limited to a
single file).
I had a look, to augment the little I knew of the NS30000 ISA. It is
very similar to the 68k in many ways. I think you'd have to dig into
fine detail to see real differences.
So, again, what do /you/ think is "inferior" about the 68k architecture?
Either I'm missing something, or you are missing something.
I used it for the implementation of a channel encoding system, a
typical "signal processing" application; it was great. Imagining
I would have to use any other processor I already knew these days
(65xx, 68k, x86)... - that would have been really annoying.
There's no doubt that the TMS320 devices can be used to do many types of DSP-style operations very efficiently. That's not the point - that does
not stop it from being horrible to work with. (It is also fair to characterise it as an "interesting" architecture - that is also not at
odds with being horrible to use.)
[...]
There are plenty of things I find disappointingly similar between most
cpu architectures. It's hard for novel ideas to break through.
But there were ideas! But not only the interesting ideas (like the
frame shift on the stack [SPARC]; one detail I memorized) should have
been considered,
Yes, I like the register window idea of the SPARC. But it is hard to
make it scalable - it would be significantly more flexible if the
register window was actually a memory window with a specialised cache
setup.
also (e.g.) support of addressing data structures as
known from (back then) contemporary languages; the NS 32xxx supported
that for example.
Can you give an example?
There was, back then, a tendency for CISC processors to have a lot of complicated addressing modes to access certain data structures.
It was
later shown that these were inefficient and limited, and it was better
to have faster register calculations and do the addressing calculations
in software - for the 68030 and 68040, compilers ignored the complicated addressing modes and did the scaling and indirections in software
because it was faster.
Later implementations of the 68k ISA, like the
Coldfire, dropped the messiest address modes entirely. Of course, the NS32000 didn't have the address registers of the 68k, so the balance
might have been different there.
And these ideas were already old; see for example
Seegmüller: Einführung in die Systemprogrammierung (1974)
(And I would be surprised if he'd been the first who described that.)
But yes, the "break through" factors (e.g. the market factors) were
an issue.
[...]
I can recommend reading about the XMOS. (It's for embedded use, not a general-purpose processor.)
On 28.03.2025 10:13, David Brown wrote:
[...]
[ NS32032 ]
Indeed. After all, the 68k was one of the most successful ISAs ever,
and the x86 "won" for economic reasons, not technical reasons. The
NS32000, on the other hand, is known only to a few nerds. [...]
Given that it did not "survive" in the first place I was astonished
that when I spoke with IT professionals in the past it was mentioned
as outstanding (compared to a lot of other alternatives these days).
I was also astonished that bart had it in his short-list. So I'm not
inclined to accept your words that it's "known only to a few nerds".
(It's not necessarily the best technologies that "survive".) YMMV.
[...]
Later on, on web, nearly all mentions of NS32K I encountered were in
context of examples of extreme CISC. I.e. MUCH CISCier than x86, significantly CISCier than even such rather heavy CISCs as VAX and
MC68020. Of course, not quite complicated as Intel iAPX 432. So, it
seems, it is remembered, but not in a good way.
On 27.03.2025 12:14, bart wrote:
On 27/03/2025 02:24, Janis Papanagnou wrote:
I'm speaking about all that inferior systems that had a comparably
high price without a matching quality. And about years and years
passing without vendors of such products changing that situation.
I guess ... you're talking about either the IBM PC hardware or MS
software, or both? (Although PCs weren't expensive.)
Here PCs were expensive; a friend of mine bought one for ~8000 DM,
IIRC, (compare that to 2000 DM for a Commodire PET; even the first
Apple was expensive but not that expensive as the IBM PC).
I've never used Basic. But it is one language I admire, even if it is
crude:
10 let a=0
20 let a=a+1
30 if a<1000000 then 20
40 print a
Okay, you "admire" BASIC (and you found the 68000 CPU "wonderful");
that tells a lot about your background and expertise.
I seem to recall that elsewhere in the thread you were mentioning the
number of transistors - I understood that as if you take that being
an indication for a complexity, non-triviality, not being "primitive".
If that is a correct interpretation of your argument I'd like to
suggest considering that the number of molecules (necessary to build
up these ~8000 transistors) is even larger.
Try for a moment to understand that the quality of a CPU architecture is
not (for assembler programmers) something measured in transistors.
If you mention 68000 and NS32032 playing in the same architectural
league then it's hard for me to consider you a serious discussion
partner.
I won't discuss the details of CPU architectures with you here; but
if you're really interested I suggest to inspect those two processors
more thoroughly - there's papers and documents available online.
[...]
But that all was long ago and is meaningless today.
I find I can learn a lot from how simple things were that long ago. The
early 80s was the golden age for that, getting away from mainframes and
complex OSes, to much more informal systems. Now it's worse than ever.
I'm not able two bring your two sentences together. - What is worse?
Do you mean to qualify it as: mainframe era: bad, 1980's era: good,
nowadays: bad again. - Is that what you wanted to say?
Lets say I have some background to separate the wheat from the chaff.
("IT" means "information technology"; a common superordinate term to
not enumerate all the subareas separately. - I'm sure you know that.)
On 28/03/2025 10:22, Janis Papanagnou wrote:
[ NS32032 ]
Indeed. After all, the 68k was one of the most successful ISAs ever,
and the x86 "won" for economic reasons, not technical reasons. The
NS32000, on the other hand, is known only to a few nerds. [...]
Given that it did not "survive" in the first place I was astonished
that when I spoke with IT professionals in the past it was mentioned
as outstanding (compared to a lot of other alternatives these days).
I was also astonished that bart had it in his short-list.
You are astonished that I'd heard of it?
Did I mention that I was a hardware engineer at that time?
On 28/03/2025 11:22, Janis Papanagnou wrote:
I was also astonished that bart had it in his short-list. So I'm not
inclined to accept your words that it's "known only to a few nerds".
(It's not necessarily the best technologies that "survive".) YMMV.
Bart is a nerd of rare quality. (I mean that in a good way.) It does
not surprise me that he is familiar with it.
[...]
On 27/03/2025 01:10, Waldek Hebisch wrote:
bart <[email protected]> wrote:
On 26/03/2025 18:09, Janis Papanagnou wrote:
, primitive CPU architectures,
8-bit architectures were fine, just a bit short of registers and with
limitation instruction sets. But that is to be expected with only 27,000 >>> transistors on a chip or whatever it was for Z80.
All sources that I found say that Z80 is about 8000 transistors.
You probably took number from 8086 which was climed to have 27000
transitors.
OK, then with 8000 it makes the capabilities even more remarkable.
Current processors have billions of transistors.
Z80 (like earlier 8080) in "general" instructions required
accumulator as one of arguments, that severly limited utility
of registers.
(BTW, have a go at emulating such a processor in sofware; tell me in 3
months how you got on.)
Lone processor is not very interesting. I do not think coding
simple emulator would take a lot of time. Z80 instruction set
is a bit bulky, due to prefixed instructions, but decode could
be done quite naively using 5 tables with 256 positions each
(or a bit smarter using 3 tables)
I don't think this is the one I saw, but the z80.c file here:
https://github.com/redcode/Z80/tree/master/sources
is nearly 3000 lines. There is a lot of stuff consider!
In my case, I wanted something performant, but I could see 90% of
emulation time being spent in multiple flags most of which would never
be tested.
On 27.03.2025 12:14, bart wrote:
On 27/03/2025 02:24, Janis Papanagnou wrote:
I'm speaking about all that inferior systems that had a comparably
high price without a matching quality. And about years and years
passing without vendors of such products changing that situation.
I guess ... you're talking about either the IBM PC hardware or MS
software, or both? (Although PCs weren't expensive.)
Here PCs were expensive; a friend of mine bought one for ~8000 DM,
IIRC, (compare that to 2000 DM for a Commodore PET; even the first
Apple was expensive but not that expensive as the IBM PC).
[...]
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 155:45:28 |
| Calls: | 12,092 |
| Files: | 15,000 |
| Messages: | 6,517,709 |
