On 17/03/2020 11:17, Jan Panteltje wrote:
> On a sunny day (Tue, 17 Mar 2020 11:16:38 +0100) it happened "A. Dumas"
>  wrote in :
>
>> On 17/03/2020 08:18, Jan Panteltje wrote:
>>> Not so sure about that, once tried the latest download
>>> and tried it in my old PI, and it did not even boot.
>>> Checksum was OK, no download error.
>>
>> Something else was wrong. The old full-size SD card slots were wonky,
>> maybe that failed? All downloads of the RPi Foundation work with all
>> RPis. That's precisely the reason why they stayed on 32-bit.
>
> Possible, but bit unlikely, been using those SDcards without problems for
years.
> And, even if it booted, then it still would not work for some
> software due to the GPIO addressing, example:
>   http://panteltje.com/panteltje/newsflex/download.html#freq_pi
>
>
> I usually get a recent release, like that Buster for my P4,
> and from that point onwards modify it, never 'upgrade'.
> If I ever buy a Pi5 ?? same procedure ;-)
>
> What would a Pi5 be able to do? Interesting question.
>
> Maybe it is my hardware background,
> I see the software and hardware as one thing,
> raspberry is not just an operating system (Linux)[1] but a huge wilderness of
applications.
> Expecting to - or making it to run on all models would be a very limiting
requirement.
>
> But maybe you are right, maybe it detects the processor on boot up,
> but this is my experience.
>
> [1] the function of an operating system is to as much as possible make an
> interface to the hardware that allows the same programs to run on as  many
types of hardware.
> For programs that by-pass that OS and use user space access to the hardware
> it would be a tall order to make those run on every model (they don't), needs
a rewrite if at all possible.
>
> So much for the basics part :-)
>
> My advice is keep it simple, too much spaghetti in all those releases.
>
> As to 32 bits... mm you know, programming in asm on a Microchip PIC,
> setting and testing a flag
>   btfss   spi_byte, 7
> ...
>   bsf             SPI_SCK
>
> takes ONE bit of ONE byte.
>
> Now even in C I see this:
> int too_hot;
> int alarm_flag;
> if(too_hot) alarm_flag = 1;
>
> On an int that takes 64 bit system this takes 8 bytes!
> Basically 8 * 8 = 64 x less efficient.
> Not even mentioning the memory access delay.. alignment.
> Just FYI.
>
> LOL
> And I wonder, Yes I wonder, Why
>
> But bloat sells.
> And memory per byte gets cheaper all the time
>
> Just something to think about...
>
>
>
The point is that RAM is cheap and the C example does just two memory
accesses which are the CPU time

I would say the ASM case on a small processor is slower by far


--
Gun Control: The law that ensures that only criminals have guns.

--- SoupGate-Win32 v1.05