That interview is 9 years old. Basic memory allocation means just extending the heap, but convenient memory allocation in malloc-style is also available (even if it's typically not the job of the kernel), it says so right there in the link I posted, under system call 64.

Doh, perhaps i don't even remember exactly.
But isn't it that ipl=6 allows both 6 & 7 (anything >=6) but ipl=7 only 7, while ipl=0 allows >=0 but there is no level 0 so it's the same as 1 ?

ipl=6 doesn't allow any maskable IRQ (same as 7)
ipl=0 allows >0, so every IRQ
ipl=1 allows >1, and so on

Quote:

Perhaps because TST was implemented with similar hardware as CLR, NOT, NEG, NEGX, which were all read-modify-write (including, wrongly, CLR).

Well, I can understand for the listed instructions, that are all with modification of the destination, but not for a read only operation!
(if same die part is used for this operation is sure a bad implementation, but ehi, is a 1979 project with limited transistor usable )

That interview is 9 years old. Basic memory allocation means just extending the heap, but convenient memory allocation in malloc-style is also available (even if it's typically not the job of the kernel), it says so right there in the link I posted, under system call 64.

Ok, you have the point.

Nevertheless if you look at that list, you'll see it is some vm, maybe some framework, but certainly not a fully featured operating system.
That thing is like building a tower in a swamp. A marvel of engineering maybe, but still pointless and can only end up as touristic curiosity.

So what ? Some folks managed to do something and suddenly it becomes easy ?
These people have struggled 10-15 years to do something that remotely looks like an OS.

Now please stop that menuetOS nonsense. What they did does not mean in any manner that x86 is practical to use for this, just that it is possible. And it is possible for just every available cpu.

ipl=6 doesn't allow any maskable IRQ (same as 7)
ipl=0 allows >0, so every IRQ
ipl=1 allows >1, and so on

In my memory it did put level+1 in ipl field when an interrupt occurs. I guess it's been too long i haven't fiddled with these...

But then ipl=7 would mask level 7 but they just prevented it ?

Quote:

Originally Posted by ross

Well, I can understand for the listed instructions, that are all with modification of the destination, but not for a read only operation!
(if same die part is used for this operation is sure a bad implementation, but ehi, is a 1979 project with limited transistor usable )

I must always remember not to use it

The CLR bug is a strong hint in that direction anyway. Damned electronicians always take shortcuts where they shouldn't

My only issue with the 68000 CPU is that the bus takes between a week and a month to fetch a memory address. Other CPUs had better bus interfaces (even 8 bit ones!!) so they could get better instruction throughput. The Amiga had reasonably fast ram but the 68000 never took advantage of that.

Things got a little better on the 68030.. it only takes a day to get data delivered from RAM and they finally fixed it on the 040.

Although the ARM has its flaws its memory throughput never fails to impress me.

EDIT: And the 6800 SYNC bus interface was a giant WTF. You have to wait until xmas for your data.

It most certainly does. A 1MHz 6502 manages to copy about 2000b/50Hz frame, which is about 4000b/frame for a 2Mhz one. A 7Mhz 68000, as used in the Amiga, manages closer to 17000b/frame.

Which means the 68000 has faster memory access than the 6502 - even if the 68000 where to be slowed down to 2MHz, it would still win for memory access speed.

Quote:

BBC B gets 0.5 mips at 2mhz. Same as the Amiga at 8mhz

1) the 6502 uses 8 bits per instruction, the 0.5 mips figure for the 68000 is based on it running 32 bit instructions (it’s about 1 mips for 16 bit instructions).

2) even if it where true, the 68000 instruction set and 6502 instruction set are extremely different. Merely comparing intstructions per second for two architectures that are so different is just not going to work.

I’ll give just two examples:
1) a simple move.w d(an),d0 - a very common operation - takes just 12 cycles on 68000. The equivalent 6502 code (something like ldx #2; lda address,x; tay; inx; lda address,x) will take 14 cycles. Which is slower even clock for clock, let alone if it actually ran at 2Mhz vs 7Mhz.

2) divu or mulu are so much faster than even table based 6502 versions it’s not even funny.

There are plenty more examples here. Generally, the more you want your code to actually do, the bigger the 68000 advantage becomes.

Yes. I give you it’s an apples and oranges performance comparison. Point remains... a plain 68000 takes 4 cycles to access the bus and the 6502 takes 2 base cycles. Plus the BBC makes its ram work on both edges of the clock.

Sure the 6502 only accesses 8 bits at a time and yes the 68000 is a better CPU. But it’s ram performance is awful.

There are plenty more examples here. Generally, the more you want your code to actually do, the bigger the 68000 advantage becomes.

And yet we still see people comparing very small code snippets. This pisses me off.

Quote:

Originally Posted by plasmab

Sure the 6502 only accesses 8 bits at a time and yes the 68000 is a better CPU. But it’s ram performance is awful.

This is true, but what to expect ? 6502 is designed to work on a setup where memory is faster than the cpu, and not the 68000. I'm no hardware designer, but isn't it obvious memory performance get worse as clock rate gets higher ?

Compare that to todays architectures experiencing a cache miss, and you'll see who's bad in terms of ram performance

And yet we still see people comparing very small code snippets. This pisses me off.

This is true, but what to expect ? 6502 is designed to work on a setup where memory is faster than the cpu, and not the 68000. I'm no hardware designer, but isn't it obvious memory performance get worse as clock rate gets higher ?

I can put both chips on 10ns static RAM. The 6502 theorically maxes the RAM at 200MHz. The 68000 would need to go to 400Mhz... the first ARM maxes out at 100Mhz... same for the 040.

Quote:

Compare that to todays architectures experiencing a cache miss, and you'll see who's bad in terms of ram performance

Rubbish! A 68000 needs 4x 140ns per ram access. The first access on SDRAM/DDRx is 70-80ns and it’s 10-30ns to pull each sequential memory location thereafter depending on the memory type.

You don’t know what you are talking about. I’ve built controllers for SDRAM and DDR.