Author Topic: any examples of OS not written in C/C++?  (Read 25405 times)

0 Members and 1 Guest are viewing this topic.

Offline DiTBhoTopic starter

  • Super Contributor
  • ***
  • Posts: 3793
  • Country: gb
Re: any examples of OS not written in C/C++?
« Reply #175 on: April 20, 2021, 11:29:32 am »
Well, that's why I asked.  DOS implemented a filesystem and a bunch of utilities, but had no multi-tasking and not much in the way of device drivers.A bunch of the current "RTOS" implementations give you real-time and multitasking, but no file system, utilities, or program loading capability.

I can easily add my "serial file system" to UCSO/2/3, it would just be a task with simple primitives, but the core of the RTOS itself is really too much code for me.

Years ago I wrote a minimal skeleton for a RTOS. I wrote it for the GBA (arm classic), never really completed, never used, but I can resume the project since it's less than 1K lines of C

Why do I remember it's less than 1K lines of C? Nowadays you can use Gcc for everything, years ago compiling Gcc was not as easy as it's today, and I was less skilled, so I remember I used a demo commercial C compiler that is limited to 1K lines for each C module, but since I was very lazy at that time, I didn't make "modules" (to be compiled singularly and then linked together) but rather only one big module with a lot of #include "file.inc"  :D

Oh, not bad, at least it helped make the skeleton the smallest possible  ;D
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: any examples of OS not written in C/C++?
« Reply #176 on: April 20, 2021, 02:11:13 pm »
Well, that's why I asked.  DOS implemented a filesystem and a bunch of utilities, but had no multi-tasking and not much in the way of device drivers.A bunch of the current "RTOS" implementations give you real-time and multitasking, but no file system, utilities, or program loading capability.

Digital Research did expand CP/M to MP/M and added multiprogramming.  I never used it because I was focused on a single user environment.  I ran the programs I wanted and if somebody else wanted to run something, well, they could buy their own computer.

I still remember when a 4kx8 static RAM board cost $400 and it would take 16 of them ($6400) to fully populate the memory space of a 8080.  Of course you couldn't actually get that many boards inside an Altair 8800 and if you did do that, somehow, the power dissipation would be enormous.
 

Offline MIS42N

  • Frequent Contributor
  • **
  • Posts: 510
  • Country: au
Re: any examples of OS not written in C/C++?
« Reply #177 on: April 24, 2021, 01:01:57 pm »
Interesting reading. I haven't written any higher language code for many years. I play with microprocessors and use assembler, because I want exact control over what is going on. Current project has around 50,000 interrupts/second, does a bit of multi threading, computes linear least square fits to samples on an 8-bit processor. Not sure that even C could manage it. All on 5V and a few milliamp.

When I first started writing HLL the choices were COBOL or FORTRAN. Some programs were written with segments in both with a bit of assembler thrown in. I think once one gets away from the hardware, any language can be butchered to do anything. I taught assembler to a class, gave them a disassembler written in COBOL that disassembled itself. It took a while for them to get their heads around, then they would modify the source to see what the COBOL compiler did.

All programming is a compromise between competing requirements - efficiency, portability, maintenance, security, development time, learning time. Favouring one language over another can just be due to the application and have little to do with the benefits of the language. So you want a job programming web sites - knowing Forth, C or Rust isn't going to get far - PHP, javascript, CSS and HTML, even though they are not very useful generally, will do the job. Banks use COBOL, meteorologists (I believe) use a variant of FORTRAN. I think C is popular for operating systems because to some extent it is portable, has a pool of practitioners, and introduced the pointer variable that allows all sorts of efficient manipulation. I have tried to come to grips with the C variants for microprocessors, they bend so much to accommodate the particular processor they aren't that portable. The libraries are inscrutable, maybe they work, maybe they fit. So I am not a fan.

All of which is completely off topic. I was going to mention implementing security via hardware, where only a small amount of well tested code is given full privilege, and most code is run at lower security levels (VAX VMS comes to mind). But it is late and I'm going to bed.

 
The following users thanked this post: DiTBho

Offline DiTBhoTopic starter

  • Super Contributor
  • ***
  • Posts: 3793
  • Country: gb
Re: any examples of OS not written in C/C++?
« Reply #178 on: April 24, 2021, 01:27:58 pm »
Current project has around 50,000 interrupts/second, does a bit of multi threading, computes linear least square fits to samples on an 8-bit processor. Not sure that even C could manage it. All on 5V and a few milliamp

Which CPU are you using for this?  :D
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 

Offline MIS42N

  • Frequent Contributor
  • **
  • Posts: 510
  • Country: au
Re: any examples of OS not written in C/C++?
« Reply #179 on: April 24, 2021, 09:31:51 pm »
Current project has around 50,000 interrupts/second, does a bit of multi threading, computes linear least square fits to samples on an 8-bit processor. Not sure that even C could manage it. All on 5V and a few milliamp

Which CPU are you using for this?  :D
PIC16F1455. 10MHz external clock, internal x4 PLL for internal clock, = 10MHz instruction time.
 

Offline rfclown

  • Frequent Contributor
  • **
  • Posts: 407
  • Country: us
Re: any examples of OS not written in C/C++?
« Reply #180 on: May 04, 2021, 12:21:52 am »
Interesting reading. I haven't written any higher language code for many years. I play with microprocessors and use assembler, because I want exact control over what is going on. Current project has around 50,000 interrupts/second, does a bit of multi threading, computes linear least square fits to samples on an 8-bit processor. Not sure that even C could manage it. All on 5V and a few milliamp....

Completely off topic...

I too code microprocessors (usually AVRs lately) mostily in C, sometimes in assembler. I have no idea how to do multi threading. I only do very simple stuff with microcontrollers. I completely don't understand OOP. If I Google to find a function I want and it ends out being in C++, I'll figure out how to convert it to a C function.

That said, I found out 30 years ago that I had a misperception regarding assembler and speed. I transitioned from QuickBASIC to QuickC because I believed that C was faster than BASIC. And with C, I could include inline assembly (best of both worlds). My first incentive to do this involved reading RSSI values that were in dB and computing averages quickly for a TDM power control system (dB->watts->avg). C and assembler allowed me to do this. No doubt, assembler is going to be the fastest, but... it's amazing how fast code can be if it's written well in C. I discovered that the reason my QuickBASIC code was usually slower is because I didn't define the variables up-front, and the default was floating point. If I defined variables as int, QuickBASIC wasn't slow (compiled BASIC). It was comparable to QuickC. (this was early 90's I think).

My present day HLLs are C and LabVIEW. LabVIEW runs like compiled C, but since it (I think) does some parallelizing for you (if you have multiple processors) it is amazingly fast (if you code well). A while back I wrote an OFDM vector signal analyzer in LabVIEW. I had a receiver streaming in I/Q baseband samples over TCP at 1.625 Msps. Our TDM system had a 10msec uplink, 10 msec downlink. With a 128 point FFT and 16 point CP you get about 116 symbols in a 10msec frame. The LabVIEW program would use cross correlation to find the preample, do a frequency estimation based on training symbols in the waveform, correct the data for frequency offset, equalize, demodulate, compute EVM, display whatever you wanted to look at (individual symbols, multiple symbols). I think it was 108 active carriers out of a 128 point FFT. Carriers could be BPSK, QPSK... up to 1024 QAM. And the program on a quad core Lenovo laptop kept up in real time! It could do all the computation and presentation of the signal before the next TDM frame came. I had not had any expectation that the program would keep up in real time. I was doing the work because we were looking to remove the pilots from our waveform, and Keysight's VSA (what we were using at the time to analyzer our signals) choked on that.
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: any examples of OS not written in C/C++?
« Reply #181 on: May 04, 2021, 07:26:02 am »
That said, I found out 30 years ago that I had a misperception regarding assembler and speed. I transitioned from QuickBASIC to QuickC because I believed that C was faster than BASIC. And with C, I could include inline assembly (best of both worlds).

That depends entirely on:

1) whether the CPU was designed for running compiled languages such as Pascal or C. 6502 and z80 definitely weren't, but AVR was. 8086 and 68000 weren't really but are kind of OK, but not really. 6809 was a bit later and is pretty good for an 8-bitter. Anything from MIPS and ARM and on is designed for running compiled languages and you have to work very very hard to beat the compiler.

2) how good you are at assembly language and working around and exploiting the weirdness of your CPU. Especially on 6502 and Z80 and the like. But early x86 too.


Something like LabView presents you with a high level language, but the people who wrote it made all those FFTs and so forth in assembly language, or something very close to it.
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1714
  • Country: se
Re: any examples of OS not written in C/C++?
« Reply #182 on: May 04, 2021, 07:54:17 am »
8086 and 68000 weren't really but are kind of OK, but not really.
I remember reading many years ago that the 8086 segmented memory architecture was a natural match for Pascal, easing the job of the complier:
  • The code segment is used for instructions
  • The data segment holds global variables
  • The stack segment holds return addresses and local variables
  • The extra segment holds variables accessed via pointers (IIRC, in old standard Pascal pointers are not free to point to any variable, only to variables allocated with New()
Of course, those were times when 64 kB per each segment was a respectable size...
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: any examples of OS not written in C/C++?
« Reply #183 on: May 04, 2021, 09:12:15 am »
8086 and 68000 weren't really but are kind of OK, but not really.
I remember reading many years ago that the 8086 segmented memory architecture was a natural match for Pascal, easing the job of the complier:
  • The code segment is used for instructions
  • The data segment holds global variables
  • The stack segment holds return addresses and local variables
  • The extra segment holds variables accessed via pointers (IIRC, in old standard Pascal pointers are not free to point to any variable, only to variables allocated with New()
Of course, those were times when 64 kB per each segment was a respectable size...

Right.

Yeah, it's simply untenable on a small machine for C where address arithmetic is standard and frequent, forcing every pointer to 32 bits segment:offset. It's not too bad for Pascal where you don't do arithmetic on pointers and a pointer can be just the segment number. The pain comes because there's only one extra segment so you have to keep reloading it to switch between objects, and that was slow (maybe not on original 8086). Pretty soon 64k got to be too small for array or big buffers for many programs. Even when you has only 1 MB you might want to do some scientific calculation using more than 64k for one array.

68000 had a similar problem in that there was only a 16x16 multiply instruction. Both MPW and THINK Pascal only took a 16 bit result from that, so array sizes were also limited to 64k there. I don't know why they did that when the MULU/MULS instructions *always* produced a 32 bit result.

At one point I got Rich Siegel to fix this from his personal copy of the THINK Pascal source code and send me the resulting compiler. This made things much much better as then you could have up to 64k elements of up to 64k bytes each. I may be the only person in the world who ever had a copy of this version of the compiler.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: any examples of OS not written in C/C++?
« Reply #184 on: May 05, 2021, 08:28:12 am »
1) whether the CPU was designed for running compiled languages such as Pascal or C. 6502 and z80 definitely weren't, but AVR was. 8086 and 68000 weren't really but are kind of OK, but not really. 6809 was a bit later and is pretty good for an 8-bitter. Anything from MIPS and ARM and on is designed for running compiled languages and you have to work very very hard to beat the compiler.

The z80 was fine for C, inasmuch as it was fine for anything. But the IX,IY registers were surprisingly limited for most things. All the z80s bolt-on warts goodies made me appreciate the risc-like simplicity of the 8080 :)

The key point about C is that it assumes the memory model is a single uniform address space where a each byte is uniquely addressable. That matches the 6800/9, 8080/8085, 68k, but not the 1802, 6502 and especially not the 8086/8.

Remember the horrors of determining whether two segment+offset 8086 pointers referred to the same object, and all the horrible grotty workarounds to try to make it less grossly inefficient? Shudder.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: any examples of OS not written in C/C++?
« Reply #185 on: May 05, 2021, 08:56:27 am »
Oh I'd forgotten about that. Thanks for the headache. Going to dream about FP_ macros and far pointers tonight now  >:(

I inherited someone's code once and they didn't understand it when they wrote it. That was not much fun. After about a week of banging my head on it I actually rewrote the whole damn thing in VB for MSDOS which took less time than unfecking it. As a bonus that hid the problems away.
« Last Edit: May 05, 2021, 08:59:01 am by bd139 »
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: any examples of OS not written in C/C++?
« Reply #186 on: May 05, 2021, 10:15:45 am »
The key point about C is that it assumes the memory model is a single uniform address space where a each byte is uniquely addressable. That matches the 6800/9, 8080/8085, 68k, but not the 1802, 6502 and especially not the 8086/8.

6502 address space is fine. 64 Kib, flat.

Unless you've plugged an expansion card in that gives you a MB or two of RAM in banks of .. 4K? 16K? I don't know, I never used one.

The problem with 6502 is when you feel as if it's got no registers. Until you realise you should treat Zero Page as the real registers, at which point you've got a zillion of them. Dedicate a couple of ZP bytes as a User Stack Pointer, then partition a bunch more in the same way as PowerPC, Aarch64, RISC-V etc have 8 or 10 registers for arguments/locals/temps, a dozen or so for callee-save variables, and a few for temps that no one owns. If you allocate them as 16 bit pseudo registers then you've probably only dedicated around 64 bytes so far, leaving 192 for goodness knows what. Then use the same kind of calling convention as the above RISCs with arguments and return value in the caller-save registers. If you need to use some callee-save registers then copy them en-mass to the User stack at the start of your function (use a subroutine for this) and copy them back just before you return. You may as well use the hardware stack for function return addresses -- unless you're planning to recurse more than 128 levels deep (unlikely) --  but basically nothing else.

You can make some very pleasant 2-address 16 bit (or 32 bit) arithmetic routines where you load the dst ZP register number into X and the src ZP location into Y and then call a function.

Code: [Select]
add16:
    clc
    lda $00,X
    adc $0000,Y
    sta $00,X
    lda $01,X
    adc $0001,Y
    sta $00,X
    rts

Twice (or more) as compact to call as to use inline code, and about 60% of the speed (more for 32 bit functions)

Code: [Select]
ldy #src  ; might already be correct, so can often be omitted
ldx #dst  ; might already be correct, so can often be omitted
jsr add16

Not quite as compact as SWEET16 or USCD P-system etc bytecode (but not far off), but ~5 times faster.
« Last Edit: May 05, 2021, 12:15:44 pm by brucehoult »
 
The following users thanked this post: newbrain

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: any examples of OS not written in C/C++?
« Reply #187 on: May 05, 2021, 10:26:39 am »
6502 is flat, and - despite never having used one for more than a 30byte demo program - I'm sure you are right about regarding zero page as all registers.

However, ISTR there not being any instructions that operated on 16-bit offsets/pointers - you had to synthesise them every time you wanted them. The 6800 was much better in that respect with IX and IY.

As for 256 registers, I'm unconvinced of their utility for HLLs of the time which couldn't do very much global register optimisation. The amd29000 also had vast numbers of registers (?192?), but they weren't easy for a compiler to use effectively.

OTOH, I can easily see how an interpreter could make use of 256 "special purpose" registers.

I've always said that computers (and their programmers) are like crows. Their counting ability is 0-1-many, since other numbers are too difficult to deal with :)
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: any examples of OS not written in C/C++?
« Reply #188 on: May 05, 2021, 10:35:38 am »
Best use for zero page on the 6502 is stack as it’s cheaper to access it. I think ARM started as 32 bit 6502 with orthogonal register utility. Apart from the bastard 26 bit PC/flags that cursed the first few chunks of silicon.

Compiler should make register allocation decisions based on what it’s compiling. Itanium was designed around that concept. The actual architecture was impenetrable by humans. We probably should let the machines design the ISA at this point like we do with the silicon.
« Last Edit: May 05, 2021, 10:37:52 am by bd139 »
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 19280
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: any examples of OS not written in C/C++?
« Reply #189 on: May 05, 2021, 11:00:17 am »
Best use for zero page on the 6502 is stack as it’s cheaper to access it. I think ARM started as 32 bit 6502 with orthogonal register utility. Apart from the bastard 26 bit PC/flags that cursed the first few chunks of silicon.

Compiler should make register allocation decisions based on what it’s compiling. Itanium was designed around that concept. The actual architecture was impenetrable by humans. We probably should let the machines design the ISA at this point like we do with the silicon.

Roger Wilson and Steve Furber were indeed heavily influenced by the 6502 when creating ARM1. I've never really understood how, because the ARM1 always felt as clean as the PDP11 vision.

But back when 6502/z80/8086 were new and interesting, C compilers were so primitive they still took note of the "register" keyword! (Now the problem is they are so damn complex that very few people can predict what strange "bugs" they will generate with higher optimisation level.

(C lawyers and purists will, arguably correctly, state that the "bugs" are programmer errors. I tend to regard them as language committee specification errors :) )
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline bd139

  • Super Contributor
  • ***
  • Posts: 23017
  • Country: gb
Re: any examples of OS not written in C/C++?
« Reply #190 on: May 05, 2021, 11:57:44 am »
I think the ARM1 was mostly clean because it was new and minimalist. Newer ARM cores are somewhat more raggedy.

As for optimisers, that's mostly GCC which turns out rubbish to be fair. I haven't noticed clang do anything quite as terrible at high optimisation levels. I think my favourite one was GCC unrolling a variable cycle loop. Not sure how it worked out that was possible  :-//

I am on the fence with respect to "bugs". Some are programming errors, some are language specification error but the majority in experience are actually not understanding the task that is required to start with to a sufficient degree and winging it hoping that if the problem is solvable that you do enough of it to get paid.
 

Online brucehoult

  • Super Contributor
  • ***
  • Posts: 3996
  • Country: nz
Re: any examples of OS not written in C/C++?
« Reply #191 on: May 05, 2021, 12:12:16 pm »
Best use for zero page on the 6502 is stack as it’s cheaper to access it.

Ahhh .. I'd contest that.

Ok, you could use X as a kind of stack pointer into zero page and do a PUSH A as "STA $00,X; DEX" and POP A as "INX; LDA $00,X". But those are both 4 + 2 = 6 cycles while the actual PHA is 3 cycles and PLA is 4 cycles. Plus you're using 3 bytes of code instead of 1. And you lose a scarce register! Hard to see the point.

The *only* advantage is you can use LDA $01,X STA $02,X etc to directly access stack elements other than the top one, which you can't do with the real stack.

But with the real stack you can do TSX then LDA $0100,X or STA $0101,X etc if and when needed as a cost of 2 cycles for the TSX and 4 cycles for loads or 5 for stores -- the same timing as for Zero Page for loads, and 1 cycle more for stores.

Quote
I think ARM started as 32 bit 6502 with orthogonal register utility.

Not at all. The ways in which 6502 influenced ARM are well documented as:

1) the 6502 uses basically every available bus cycle. You can mostly understand the execution time of programs as being the number of bytes of instruction fetch, loads, and stores they do, with just a couple of exceptions (2 cycle minimum, and extra cycle for indexed addressing modes that need a carry from low byte to hight byte)

2) Wilson and Furber visited the Western Design Center to discuss them designing a 32 bit chip for Acorn. The WDC weren't interested, but the Acorn people were stunned at how few employees there were and figured that if WDC could design CPUs then so could they.

Quote
Compiler should make register allocation decisions based on what it’s compiling. Itanium was designed around that concept. The actual architecture was impenetrable by humans. We probably should let the machines design the ISA at this point like we do with the silicon.

I disagree with that too :-)  But then I'm spending quite a lot of my time helping design and evaluate RISC-V ISA extensions.

Certainly it's very useful to use the machine to help you sift through existing code looking for improvement opportunities and evaluating the magnitude of them, rather than just going off hunches, but there's still a heck of a lot of good taste involved.
 
The following users thanked this post: newbrain, bd139, SiliconWizard

Offline MIS42N

  • Frequent Contributor
  • **
  • Posts: 510
  • Country: au
Re: any examples of OS not written in C/C++?
« Reply #192 on: May 06, 2021, 02:37:16 pm »
Some of the best (or worst) 6502 code I saw was the BASIC interpreter - 8kbyte of spaghetti (I didn't see the source, just disassembled it). Amazing that it packed all the functions in, dynamic strings etc. I had the interesting task of implementing a sliding windows error correcting protocol (X.PC) on a C64. It had to play nicely with the BASIC because the application was written in BASIC. It was possible to disable the BASIC ROM and access the 8K of RAM that occupied the same address space. So most of the code and buffers were 'invisible'. The O/S had to be hacked also, to implement a bit bashing 1200 baud software UART (the C64 doesn't have one).

I agree that ARM architecture is better handled by HLL.

Multithreading on a processor is pretty straightforward. When a process is interrupted, some of the state has to be saved so it can resume without corruption. If the interrupt moves that state somewhere, it can then enable interrupts and be interrupted itself. It just has to put back the state of the interrupted process on completion and return. I am using the technique to deal with NMEA messages from a GPS module. There is a background process that does some calculation every second, and an interrupt routine to buffer incoming NMEA characters as each character is received. When a full NMEA message is buffered, the character receiver saves the state of the background, branches to the message handler and enables interrupts. That allows the message to be parsed while another buffer is being received. After parsing, the background process state is put back and the parser returns. The background process eventually picks up the parsed data. There is a timing issue that the parser has to complete parsing a message before the next buffer is filled. In real life there's plenty of cycles to spare.

I wanted to run the PIC16F1455 from a precise voltage. The MAX6350 provides 5V up to 15mA, stable to 4uV/C. Wondered if that was enough. Measured the processor current, up to 5mA at times.  Cheering.

 

Offline DiTBhoTopic starter

  • Super Contributor
  • ***
  • Posts: 3793
  • Country: gb
Re: any examples of OS not written in C/C++?
« Reply #193 on: May 06, 2021, 03:03:36 pm »
I love linear addressing. Seriously, I love it!

I am playing with two 8bit MPUs attached to a shared ram. 2Kbyte of dual port ram, 32Kbyte of ram, 8Kbyte of rom.

This toy needs a kernel, a pico kernel, a femto kernel, even only a simply scheduler, something to sort out a very wild parallel computing.

Each node runs four tasks cooperative scheduled, the node-A is a producer, the node-B is a consumer, and the dual-port between them is what they use to communicate, push, and pop data.

I am still programming everything in assembly.
The opposite of courage is not cowardice, it is conformity. Even a dead fish can go with the flow
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf