SIXTYFORTH?

If I remember correctly, CHAR is specifically restricted to 8 bit in Forth language specification, to keep compatibility with other Forths. CELL is

64 bit on 64 bit machines, 32 bit on 32 bit machines, etc.

Reply to
Pabst Blue Ribbon
Loading thread data ...

OK.

OK. That is really another way of saying Richard Kettlewells point, that the bottleneck is memory access, and that sparse data in memory makes for more memory accesses.

Well I knew that already. More to the point it looks like increasing memory speed is also at an end.

And although HD=>SSD was a huge step up, thats pretty much done and dusted.

Only one place left to go. Tackle bloatware :-)

--
The lifetime of any political organisation is about three years before  
its been subverted by the people it tried to warn you about. 
 Click to see the full signature
Reply to
The Natural Philosopher

Send it direct to Alexa/Siri.

But joking apart, I suspect that the shortage of competent people will cointinue as it alsways has, and that one or two really good coders will wrote a system where you just tell it using voice commands what you want it to do, and it writes the best code possible.

The library is in code algorithms that the AI coding platform knows..

Then OOP and all the other rubbish that is designed to make bad coders less incompetent, can be dispensed with.

--
Karl Marx said religion is the opium of the people. 
But Marxism is the crack cocaine.
Reply to
The Natural Philosopher

The writing was on the wall for that when CPU cycle times went down much faster than memory access times.

It looked that way just before NVMe, I saw some discussions around the possibility that DRAM may become obsolete with NVMe SSDs filling cache lines directly.

Nope there's still power consumption to attack or rather being attacked. Run your mind back to the time a bleeding edge PC was about as powerful as a RPi3 and consumed the thick end of a hundred watts.

Big data centres don't particularly need faster processors or faster memory they already hold tens of thousands of processors and hundreds of thousands of discs - they do need denser storage and lower power consumption.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

If that is to program in parallel then yes. Otherwise, program in parallel...

--
--
Reply to
Björn Lundin

Or use a language that questions that what you write is what you want. It has been said that the language does not matter, that a good coder makes good code in any language.

However most programmers are not good. They are medioker at best and a small portion is bad. It's the normal distribution that say so. Still they code.

Give a medioker coder a bad language, the outcome is buggy and bad. Give a medioker coder a good language, the outcome is more often ok to good and usually at least medioker. Seldom bad.

Language do matter for the overall outcome.

Of course, some of you say that they should get out of programming. Yes they should, but they don't. They need a job just as a medioker/bad plumber does.

Already in the early 90'ies there is a nice story of how a software contractor thinks that their programmer (in assembly) can outperform a compiler for a high level language (Ada) for speed and/or size in an embedded environment.

How wrong they were. story at

For the lazy, I put the abstract here

Abstract

With the intent of getting an Ada waiver, a defense contractor wrote a portion of its software in Ada to prove that Ada could not produce real-time code. The expectation was that the resultant machine code would be too large and too slow to be effective for a communications application. However, the opposite was verified. With only minor source code variations, one version of the compiled Ada code was much smaller while executing at approximately the same speed, and a second version was approximately the same size but much faster than the corresponding assembly code.

And this in a 1/4 of the coding time ...

--
--
Reply to
Björn Lundin

You don't remember correctly. The character size is at least 8 bits. Forth-94 and Forth-2012 even allowed 1 chars > 1, but the next standard requires 1 chars = 1. The OP's suggested system could be compatible with the next standard by having a 64-bit address unit. I think that 64-bit chars on byte-addressed machines are a bad idea, though. They don't solve a problem, and cause various compatibility and performance problems.

Followups set to comp.lang.forth.

- anton

--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html 
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html 
 Click to see the full signature
Reply to
Anton Ertl

It really isn't Elizabeth - things get very complicated very quickly once you get to certain levels. The last time I looked nobody else in the world could achieve that number of threads despite years of trying. (China,France, Russia etc) I think the closest was about 300,000 (again USA) For instance - what sort of fault tolerance would you be building in? (a much bigger question than it appears at first) there are tasks and there are TASKS. But are all tasks threads? No - different animal. .

Threads not tasks... To give you another suprising fact - parallel computer design is now moving away from caring about how many machine cycles are taken. Spending time worying about that is counter productive. (Sorry I can't recall the reference for such a bold statement)

It's apples and carrots Elizabeth.

40 years ago I was installing mini-computers (chip-slice) with 50 users myself. But bashing in court records or the gold price changes manually isn't doing the quite the same sort of task that calculating to visualise the atoms positions in a fusion reactor is. It's a very different level of computing. One requires a task swap the other a threading spread.

I'd love to see the Forth tools you'd use to even begin such a project today. To be sure parallel Forths have existed - (see john dorband on the MPP) but hardware today requires software tools of a totally different order of magnitude - and neither switforth nor vfx has anything approaching a usable toolchain for such purposes to the best of my knowledge.

To be fair - such things are still in their infancy (Try VTK-m) but I know of no one who would choose Forth (as it currently exists) for such a job. And half a dozen engineers of any calibre can't joyride their way through most designs anymore. (And if they could - no competent project manager would allow it) Understanding hardware is no longer the key requirement. Those of us that do know a little have an advantage (As Fred P. Brooks showed) but hardware knowledge isn't that much of a contributing factor anymore.

The world turns. Things change. Creativity is key once more. What is Forth Inc doing about Industry 4 for example? Already it's becoming a bit late to get on that bus. Even hiding in the discrete embedded world won't be an option in just a few more years.

Its isn't about machine cycles anymore. Forth can't win on that score. Even the approach to software philosphies has changed. The paradigm shift is towards process structure not data structure now. (David May - Bristol U) or wave processing or a few other trippy concepts. Forth COULD make a big impact here - but sadly it has no foundation.

While my interest is obviously the leading edge of this stuff it is already beginning to filter down a little and as someone once said - if you sleep - you loose. Forth went to sleep 30 years ago.

--
john 

========================= 
 Click to see the full signature
Reply to
john

formatting link

--- here it is

formatting link

formatting link

OOP is far from being rubbish designed to make bad coders less incompetent (that's Enterprise Java Beans and all that grows from them) OOP is an effective paradigm for structuring complex systems.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

AIUI, because today's compilers apply and re-apply several layers of optimisation and do so regradless, that it is now well nigh impossible to code more effectively in assembler.

But that is not to say that assembler is not fun in an amateur environemnt, because staying close to an admirable complex machine is so rewarding!

Reply to
Gareth's Downstairs Computer

Shades of the claims made for The Last One

Reply to
Gareth's Downstairs Computer

I found myself laughing uncontrollably when I saw the advert for

"The Last One - Mark 2"

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

Yes. That makes sense BUT it wont actually make e.g. my desktop any faster because it spends almost no time now on IO wait

Yes, but that has not much further to go either. It is an expression somewhat of morres law. As gate size gets smaller so too dpoes te power, exspecially if the clock rate is lowered

ARM is economical because there wasn't a lot in it, because Acorn could not afford a bigger gate array to build it on

And they will get that a bit.

Certainly virtualisation has stripped machine rooms of vast quantities of tin that was mostly idle, consuming power.

I.e. what I an saying is that there ain't no low hanging fruit left, although sime is, agreed, lower than others

--
"In our post-modern world, climate science is not powerful because it is  
true: it is true because it is powerful." 
 Click to see the full signature
Reply to
The Natural Philosopher

Gary Kildall is recounted to have, whilst a student in a summer job, rewritten a whole application in FORTRAN raher than assembler..

It was smaller and ran faster.

Which doesnt prove anythung much beyond the fact that he was a good coder.

--
?it should be clear by now to everyone that activist environmentalism  
(or environmental activism) is becoming a general ideology about humans,  
 Click to see the full signature
Reply to
The Natural Philosopher

Indeed. Ceratinly the few times I have disasembled C code - or rather compiled to assembler - I have been alarmed at how snart it is.

The last time I used assembler was to write a device driver that need to access I/O ports. And then only a few lines of it.

There is an argument to say that all high level languahes are simply better ways to write assembler, but there is another view, and that is that all high level languages constrain you to write assembler in a particular way - viz my example of a 'call table' that proved impossible to code in C using the compilers to hand at the time I tried.

I still dont know how to do it.

(an array of pointers to functions such that the function executed is based on pointers whose index value is passed).

Likewise C cannot return more than one value from a function directly. And yet typically there are a LOT of registers that can be used to return values from functions

int, float, char gobble(char* text) { return (len(text),atof(text),text[1]); }

OUGHT to work

so that

a,b,c=gobble("35.67");

is a valid statement

OTOH writing stack based temporary data in assembler is horrendous. In C it's trivial.

Hence my not as joky as you might think assertions that languages designed to achieve results, not dictate how they are achieved, might be the next step.

Neural net stuff. write code till the desired result is achieved in the smallest footprint and the greatest speed.

There is an apocryphal story about someone who decided to use the algorithm of 'perturb and optimise' on some CFD software that it was hoped would replace wind tunnels. Adding in some structural strentgh and stability calculations as well, he set the algorithm going with a cube.....

..and watched as the shape evolved into a seagull.

--
"Anyone who believes that the laws of physics are mere social  
conventions is invited to try transgressing those conventions from the  
 Click to see the full signature
Reply to
The Natural Philosopher

or in other words rubbish designed to make bad coders less incompetent :-)

--
The biggest threat to humanity comes from socialism, which has utterly  
diverted our attention away from what really matters to our existential  
 Click to see the full signature
Reply to
The Natural Philosopher

Many modern languages support multiple return values - the world has moved on since C l-)

--
https://www.greenend.org.uk/rjk/
Reply to
Richard Kettlewell

or that the Assembly programmer was poor, or even simply that the Compiler writer was a better programmer that the assembler programmer.

Another possibility is that the assembler program was more robust & performed more error checking, making it a better* program possibly all of the above.

There are many unknowns in this tale.

*Better is as much as being less likley to crash
--
Disclaimer: "These opinions are my own, though for a small fee they be 
yours too." 
 Click to see the full signature
Reply to
Alister

It will if the NVMe SSD can fill the cache lines faster than DRAM can (which is not yet the case).

True but it is the fastest moving development today.

There's quite a lot in an A72 core but I can still run two of them and eight A53 cores in my phone.

They're getting it quite a lot at the moment - drives and SSDs are still getting bigger, faster and lower power at quite a rate. This is more visible at the 'enterprise' end of the business rather than the 'consumer' end.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

In the same sense that Hilti make tools to make bad DIYers look less incompetent :) OOP in the hands of a good programmer is amazingly effective.

--
Steve O'Hara-Smith                          |   Directable Mirror Arrays 
C:\>WIN                                     | A better way to focus the sun 
 Click to see the full signature
Reply to
Ahem A Rivet's Shot

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.