On 28.03.2025 11:03, David Brown wrote:
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.
No, that's just not true.
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.
Yes, that is partly true. But the language by itself is inferior;
it was by design already so before it spread in contexts of home
computers.
[...]
>
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.
Erm, no.
You have said yourself what the focus of Dijkstra's statement was,
and I said what the arguments of that local professor had been.
It's unnecessary to make unfounded hypothesis just for the argument.
Concerning BASIC, there's obviously criticism on various levels.
>
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.
Huh? - Really, calm down! You are talking nonsense now.
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.
You are talking nonsense again.
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).
Yes. And you can derive a couple things from that. (Think about
it yourself.)
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.
Yes, I suggest to do that. (Some are quite obvious, not so
much "fine details".)
So, again, what do /you/ think is "inferior" about the 68k architecture?
Either I'm missing something, or you are missing something.
As said, I don't want to start a CPU discussion here and I'm
also not interested in [to me] now irrelevant CPU specifics.
(After that long time I could still name a couple things but
I'll not feed fanatics with some [strange] affinity to that
CPU.) You seem to take that technical topic very personal.
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.)
Yes, you already said so that you found work with it horrible.
(I'm not going to argument against your personal feelings.)
But it's not (not only) the DSP-specific "efficient operations"
that makes the DSP architecture interesting. Although, even the
_standard operations_ were slow on the 68k and fast on that DSP:
+, *, / in 4-6, 80, ~150 cycles vs. 1, ~1, ~16 cycles.
The things that I had in mind were the implicit post-increment,
register-switch, scaling (during pre- and post-load) - i.e. all
done at _no extra costs_. (BTW, things that are useful e.g. also
for higher-level *p++ semantics; but it goes even farther.)
[...]
>
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.
Yes, sure.
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?
Consider access to nested structures of arrays/record (Pascal). I
don't want to elaborate on all that (what I consider should be
basic knowledge) but refer to the book I mentioned (still quoted
below).
There was, back then, a tendency for CISC processors to have a lot of
complicated addressing modes to access certain data structures.
Erm, no. It is not about "*certain* data structures"; it's about
_common_ structures in contemporary languages and programming.
(See Seegmüller.) - (Maybe you have something different in mind?)
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.
Indirections is actually one of the mentioned addressing modes;
but not only in the later versions of (e.g.) the 68k series, but
already in the old ("unsuccessful") NS CPU; that was the point.
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.)
Thanks. (But as said, I'm not any more interested in CPUs today.)
Janis
Suggested method for returning a string from a C program?
Re: Suggested method for returning a string from a C program?
