Yoicks ! ! ! ! ! ! ! ! !

Try running Firefox on a 3B+ (1 GB). It takes about 20 seconds for the initial window to appear and about 55 seconds (35 from initial window) for the BBC News page to appear (this is the browser's home page).

On the Pi4 (8 GB), the BBC News page is displayed within about 10 seconds, of which the first 8 is waiting for the window to appear.

There is also a big difference in CPU usage (as shown by the widget on the taskbar). On the 3B+, starting FF increases usage from about 3% to about 70% and stays there; on the 4 it increases to about 60% but only for about 10 seconds after which it reverts to 5%.

Libre Office is much less of an issue: about 10 seconds to open Writer on both 3B+ and 4, and negligible increase in CPU usage.

Thanks for looking anyway: as I said, I had a fairly careful search of their website but only the BASIC was mentioned - that I could see anyway. Its nice to know that I didn't miss anything.

I presume the PIC C compilers you did find were cross-compilers?

That was the really nice feature of PL/9: it generated really nice code and had a compiler option was to display generated assembler as test, complete with opcode mnemonics, as well as your names for labels and variables.

Its one limitation was that it didn't optimise code between PL/9 statements, IOW a statement never left variables in registers or on the stack ready for the next statement to use.

That said, I was never able to improve code generated by even a more complex statement and, indeed, there was only one time I managed to rewrite a function in assembler that was significantly smaller or faster than code generated by the PL/9 compiler. That said, doing this was sometimes useful, since the compiler would accept blocks of assembler embedded in in the PL/9 source. You didn't need to do that often, though, and even then it was usually to do something really off the wall like calling a subroutine in the ROMBUG or tweaking a UART's control registers.

Yes, “integer promotions”. In most contexts, anything with a lower rank than int is implicitly converted to int (or sometimes, unsigned int) before doing anything else with it.

However that doesn’t require 16 bit operations in the object code. char a,b,c; a=b+c; ...can generate an 8-bit add, provided the compiler is smart enough to spot that the top 8 bits will subsequently be discarded anyway. So you’re into ‘quality of implementation’ questions there.

On my new second hand HP pavilion quad i5 with SSD, time taken to load Firefox 0.3 seconds, time taken to load BBC website 1.5 seconds.

Not bad for a 6 year old machine that outperforms anything the same money could have bought new.

Ok there is fibre to the house now...

The killer is RAM. Firefox has memory bugs, and so too does something in the x windows system. I have to shut down Firefox after a day or so and the windows manager every week or so

Interesting. That doesn't make sense, which is why it is interesting

Yes. There seem to be two. If you have windows then there is a whole point and click MATLAB product, and otherwise on Linux at least sdcc

"SDCC is a C compiler for the Intel MCS51 family, HC08, PIC, GameBoy Z80, DS80S390, Z80, Z180 and STM8 microcontrollers."

To load the hex onto a PIC chip meeds a bit of extra hardware - a Pickit-2 or summat - a board with a zero insert reusable chip socket, and a further bit of code. e.g.

I am not very up in this stuff but I think the pickAXE is a PIC with some form of bootloader and bios installed so it can compile and run its BASIC. So its a bit like an early home computer.

I am glad you made me do this research because the PIC chips are cheap and they are available in proper DIP packages and they have a load of ADC channels - I want something to read a control board of up to 36 pots and turn it into USB stream if I can. Speed not an issue, nor precision - 8 bits enough. And a pair of PICs look pretty perfect.

With a few pins left over to drive some LEDS with.

If I get bored enough to revisit that project...

Ah! the wonderful #asm directive. Or whatever.

I wrote loads of C libraries in assembler for X86 processors.

Its nice to mix. Dunno whether the current Gnu compilers have the ability to 'pass through assembler to the assembler....Never had to use assembler inside of Linux, ever. I think even interrupt driven device drivers don't need it

Back then, Richard, quality of implementation like Gnu C was a wet dream. One assumed the compilers were buggy, and poorly built and examining the assembler was routine if code didn't work, but it was still faster than all assembler especially for routine stuff like string handling and so on.

The job was a digital storage oscilloscope. Gould Advance, around about

IIRC there was 32k of main ROM, 16k of RAM and 16K left for paged ROM. And a digital signal processor chip that I had to write an interface to, to do signal filtering and act as a floating point coprocessor for the

On Tue, 2 Nov 2021 13:31:01 +0000, The Natural Philosopher snipped-for-privacy@invalid.invalid declaimed the following:

If it is anything like the old BASIC Stamps, the compiler phase is on the host computer -- generating an optimized byte-code. The PIC (or whatever chip Parallax used) has a byte-code interpreter, and a boot-time flasher for user "downloads".

I didn't think that the way PICAXE program compilation & installation works was obvious from the documentation, but actually doing it made things a lot clearer.

It turns out that the compilation system is designed to run on an X86 system. Its output is a binary blob which is immediately loaded into the PICAXE chip over an RS-232 serial line, where its written to EEPROM and immediately booted up, which implies that part of the loader is hardwired in the PICAXE chip. After that, the installed program simplt boots on power-up. The binary support blob thats added to the compiled code is specific to the PICAXE model being targetted - unsurprising since there are a variety of systems packaged as 0.1" DIP or surface mount and with 8 to 40 pins. They all seem to treat pin references as name symbols rather than hardware addresses, and similarly, different pins have different capabilities, e.g. input, output, UART, servo driver, many being selectable multifunction, the function wanted is selected by using the relevant name for the pin.

The only common feature seems to be that all chips have a UART thats used for loading the program into it and can be used to send trace and/or debug info back to the compiler/loader package.

As I said before, its not obvious whether complex stuff like the servo driver is implemented in hardware or is part of the binary support blob.

IOW, I suspect that PICAXE packages have extra silicon in them compared with bog standard PIC devices.

:-)

The PICAXE devices are still very affordable: the 14M2, which can drive two servos and the ESC, while the 8M2 only has a single PWM output, is still only GBP 2.70.

Apologies if I've repeated myself too much.

Same here.

Probably the last assembler I wrote was to set up the device descriptors for an OS/9 68000 system. That hardware is long gone but I'm still running a lot of the code I wrote on it with the Sculptor 4GL package.

That's now running on one of my Linux boxes, still thinking that its running under OS/9 68000, which is in turn running in an MC68020 emulator.

Hmm. I think you are not quite right. I think that the picaxe has a bit of boot code loaded into part of its EEPROM, and programs loaded over the top do not erase it. Sorta like 'Noobs' a bit.

But I'd guess that you could erase the lot if you stuck it in a PIC programmer. Price for the chip is pretty comparable with a bare PIC chip. two and a half smackers give or take.

That must be a figment of your imagination.

The old 26-bit versions could use up to 64 MiB; 32-bit versions can use up to 4 GiB. I/O has to be subtracted from that, of course.

Work is currently going on to add long page table descriptors to RISC OS 5 so that memory over 4 GiB can be used.

David

A pity you didn't know about Microware's OS/9 OS - written at Motorola's request to show off the 6809, OS/9 Level 2 handled all that bank switching and remembering which bank held what code.

It was well written, so much so that OS/9 Level 1 (no bank switching) was very easily ported to the MC680x0 mpus. I used OS/9 for years. It was quite the most bugfree OS I've ever had the pleasure to use: I never found a single bug in it.

Further to all this from 'picaxe.com'

"A PICAXE chip is a standard Microchip PIC microcontroller that has been pre-programmed with the PICAXE bootstrap firmware code. The bootstrap code enables the PICAXE microcontroller to be re-programmed 'in position' directly via a simple 'three wire' download cable connection. This eliminates the need for an (expensive) conventional PIC programmer, making the whole download programming system a low-cost USB cable. The same software and download cable is used for all PICAXE chip sizes and project boards.

If you purchase 'blank' PIC chips they will not work in the PICAXE system, as they do not contain the PICAXE firmware. Therefore always buy pre-programmed 'PICAXE chips'."

So there you have it. Its just a pre-programmed PIC chip.

But if you can handle the £20 or less cost of the PICKIT2 programming unit, you can create your own ...

To me its like the n00bs thing. sounded great, proved to be a pain in the butt, reprogrammed with Raspian from a linux machine via SD card reader and never looked back...

Shh don't go back in time and tell them - I would be out of a job!

Missed seeing that paragraph (or forgot I'd seen it).

Yes, thats clear, but isn't clear whether that is just the loader in firmware. I rather think thats all it is, because:

- when I downloaded the PICAXE compiler, I got a whiole set of binaries, each named to match one of the chipIDs:

/home/local/picaxe/bin/picaxe14m2

Alongside that are:

/home/local/picaxe/bin/qemu-i386 - the X86 emulator /home/local/picaxe/bin/wrapper - looks like a qemu control file

/home/local/picaxe/bin there's a file

Agreed - when I tackle the 'timer', I'm inclined to see what I can do with a PICO first and switch to the PICAXE only if that doesn't work out.

I wonder if anybody has got a JVM up and running on a PICO yet. That would be really great.

I won't tell them if you won't!

BTW, OS/9 Level 1 was available commercially almost a year before the IBM PC was launched with the <<cough>> wonderful <<cough>> PC-DOS as its only OS.

The PC standardised the small computer industry at a point somewhat behind where everyone else had already gone well past. It was a long time before anything that ran on it matched OS/9 or MP/M let alone unix of some flavour on a 68000.