64 bit OS

1Gb now, 32GB in 5 years' time when the 64 bit is the only RPi still in production?

Remeber Billy Gates? 640k is more than enough ...

Reply to
Gareth's Downstairs Computer
Loading thread data ...

Not relevant at present: this discussion is about an RPi 3B running a 64 bit OS NOW.

As for the future, anything that can be compiled now on both 32 bit and

64bit systems, like code I'm writing now and have been for the last 10 years, can simply be recompiled in 5 years time on systems with 64 bit or more addressing.

Indeed, the lesson is obvious: don't design or write anything that depends on the limitations of current systems, which primarily means not writing in anything lower-level than C - and certainly not in assembler.

--
Martin    | martin at 
Gregorie  | gregorie dot org
Reply to
Martin Gregorie

Worse than 8086/8? Must have been bad...

And then all that pointer fiddling. Forget the 640K barrier, it was the

64K barrier that drove me nuts. Small memory model, medium, large, huge, near pointers, far pointers, pointer normalization, shuffling things into and out of work areas so I didn't get segment wraparounds followed by inexplicable data corruption and crashes... Good riddance to all that.
--
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs) 
\ /  I'm really at ac.dekanfrus if you read it the right way. 
 Click to see the full signature
Reply to
Charlie Gibbs

On the other tentacle, if you base your living on planned obsolescence, it's the ideal strategy.

--
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs) 
\ /  I'm really at ac.dekanfrus if you read it the right way. 
 Click to see the full signature
Reply to
Charlie Gibbs

We do not seem to singing from the same hymn sheet because it's always the future that I had in mind :-)

Jolly good!

I think that my 1923 hymn book is Ancient and Modern, long before the revisions. Yours?

Reply to
Gareth's Downstairs Computer

Did a lot in 8086 assembler; never found it to be difficult or a problem.

You missed the Tiny model.

Reply to
Gareth's Downstairs Computer

I don't miss *any* of the models.

--
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

On a sunny day (27 Apr 2018 17:43:03 GMT) it happened Charlie Gibbs wrote in :

It all depends. In embedded if you write the code for a mouse or some sensor, then asm is just fine, or better, smaller chip, cheaper (if millions are produced every cent counts).

I look at things different, I buy a computer, install Linux on it, and it does what it does. I do NOT upgrade OS / kernel, I do install special drivers. After X years I buy a new one, faster, newer features, from big floppies to smaller floppies to card slots, from hard disks to flash-drives, from 80x24 text to 4048xsomething 36 bit deep graphics, you name it. Most of it is in hardware, video decoders, encoders. network, drivers.

That little bit C code I wrote will usually compile on the new system, else it is easily fixed. It does take at least a week to port all sort of things.

So things change, get used to it, I see computer and software as one thing. Tune it as fine as you want.

The new model opens new possibilities that require different approaches.

Interfaces change, standards change, applications change.

We live in a world where incompatibility sells. People buying analog TV, digital TV, HD TV, ultra HD TV, a consumer world, capitalism, throw away society, next cellphone has more features, bigger camera, other display type, different battery, what not, new 2G 3G 4G 5G, sell sell sell.

Programming languages change, you may not find a compiler for some old ones. Now we get the internet of things. Guess what, those standards will change. 'planned obsolescence' it is. Somebody once wrote: 'The fun things about standards is that there are so many to choose from.'

Reply to
Jan Panteltje

Sometimes you have to do it just because it's there!

Reply to
ray carter

Easy?it was a tiny, inexpensive chip and you could have any kind of multiply or divide you needed just by writing a couple dozen instruction subroutine.

More is more, not necessarily better.

Now if you have an application that does enough multiplies and/or divides that the performance cost is greater than the silicon cost, a firmware/hardware multiply and divide might make sense, but many applications can be designed to minimize the frequency of multiplies/divides.

--
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com
Reply to
Michael J. Mahon

Hi,

By example for mongodb.

Reply to
yamo'

Yes, computerisation now pervades all sorts and conditions of men, and who is to say that one person's interest is not relevant to that person?

As someone with a background in electronics, from Drude, through semiconductor to logic gates, TTL, SSI, MSI, LSI, PDP8, PDP11, 6502, 6303, 8086, 80186, 80386, all with some form of assembly language involvement in my professional career, low-level programming is my forte, and now retired, it interests me to want to flex my intellectual muscles on a 64 bit architecture, and the Pi3 is a relatively cheap way of doing that. In any case, it'll give experience, currently missing, on the ARM processors.

Computers are a complex machine to be understood and enjoyed for their own sake, and not to be used for application, and a pox on the C language that dissembles the real underlying machine! :-)

Reply to
Gareth's Downstairs Computer

They?ll take more space in cache, though how much that matters depends on other locality characteristics of your workload. Anything that hits main memory is so slow it?s not funny, and although while I don?t know about the Pi3 in particular, ?two fetches for a 64-bit quantity? is not necessarily an accurate model: 64-bit data busses and burst fetching in units of cache lines rather than words have been common for ages.

The advantages that applies even to small working sets are that there is more room for ASLR and other address-space security tricks, and (in both ARMv8 and x86-64) more architectural registers to play with.

Personally the reason I?m waiting for a low-hassle 64-bit OS before getting a Pi3 is that I want to acquire some familiarity with ARMv8 assembler.

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

And, subject to the availability of USB enumeration, something no more sophisticated than a CP/M 64 would suit very well!!

Reply to
Gareth's Downstairs Computer

With "RPis 1, 2, and 3, all awaiting unwrapping from the boxes" that's a bold statement.

Reply to
Andreas Neumann

formatting link

formatting link

Yes, everyone remotely involved in computing knows that. Especially dealing with a small computer like the Pi it doesn't make any sense, except maybe for academical reasons.

Reply to
Andreas Neumann

Too many interests here; keep flitting around, but loads of machine code and assembly experience elsewhere. Also got a beginners pack for the Arduino waiting under the bench; main problem the last couple of years has been an almost complete diversion into horology and clock repair and construction!

As in the old adage, "Never put off till tomorrow what you can put off till the day after" ! :-)

Reply to
Gareth's Downstairs Computer

Sounds appalling. It?s not 1980 any more. In this context ?low-hassle? essentially means Debian or a derivative thereof, for me.

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

Then you must really hate high-level languages that do all sorts of things behind your back - sort of like Einstein's putdown of quantum entanglement as "spooky action at a distance".

--
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs) 
\ /  I'm really at ac.dekanfrus if you read it the right way. 
 Click to see the full signature
Reply to
Charlie Gibbs

I'd accept that sentiment when a processor comes along that directly executes C, with the ASCII source being also the machine's code.

Similar calims made for FORTH machines have at least required lexical analysis.

a chacun son gout

Reply to
Gareth's Downstairs Computer

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.