Computing > Programming

any examples of OS not written in C/C++?

<< < (38/39) > >>

bd139:
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.

brucehoult:

--- Quote from: tggzzz on May 05, 2021, 08:28:12 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.

--- End quote ---

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: ---add16:
    clc
    lda $00,X
    adc $0000,Y
    sta $00,X
    lda $01,X
    adc $0001,Y
    sta $00,X
    rts

--- End code ---

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


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

--- End code ---

Not quite as compact as SWEET16 or USCD P-system etc bytecode (but not far off), but ~5 times faster.

tggzzz:
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 :)

bd139:
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.

tggzzz:

--- Quote from: bd139 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.

--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version