68k details

[meynaf]

Originally Posted by Leffmann

Meynaf, you're drunk. Turn the computer off and go to bed.

Nope, I don't drink. But i notice you're now doing personal attacks.

[Leffmann]

No it's not a personal attack There's a complete desktop operating system written entirely in x86 machine language. You can deny it all you want, but it won't change anything

[roondar]

Originally Posted by meynaf

Finally !
So it appears to be real asm.
Well, but that's not exactly "a whole OS", rather a small vm.

That is not the OS source code, that is code for some small applications.

The full code (for the 32 bit version) can be found here: https://github.com/marcosptf/menueto...el-sources-32b

I've never used this OS by the way, but I got interested by this thread and googled around a bit

[meynaf]

Originally Posted by Leffmann

No it's not a personal attack There's a complete desktop operating system written entirely in x86 machine language. You can deny it all you want, but it won't change anything

You call that complete ? Have a look at the API list ! They don't even have support for basic memory allocation !
(And perhaps at the list of supported machines as well.)

Originally Posted by roondar

That is not the OS source code, that is code for some small applications.

The full code (for the 32 bit version) can be found here: https://github.com/marcosptf/menueto...el-sources-32b

I've never used this OS by the way, but I got interested by this thread and googled around a bit

One of the zips actually gave that same source code.

[ross]

Originally Posted by meynaf

. ipl=0 is exact same as ipl=1 (not an annoyance but an oddity)

Maybe you mean ipl=6 is the same as ipl=7?
This anyway is unavoidable if you want a NMI...

However what makes me puzzled is the lack of tst (ofs,pc) when btst #x,(ofs,pc)* exists.
Ok ok in 020+ is implemented but WHY not in 000?


*Some assembler wrongly complain that is only 020+..

[Leffmann]

Originally Posted by meynaf

You call that complete ? Have a look at the API list ! They don't even have support for basic memory allocation !

Sure they do, using system call 64:
http://www.menuetos.net/syscall.txt

[meynaf]

Originally Posted by ross

Maybe you mean ipl=6 is the same as ipl=7?
This anyway is unavoidable if you want a NMI...

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 ?

Originally Posted by ross

However what makes me puzzled is the lack of tst (ofs,pc) when btst #x,(ofs,pc)* exists.
Ok ok in 020+ is implemented but WHY not in 000?

*Some assembler wrongly complain that is only 020+..

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

[meynaf]

Originally Posted by Leffmann

Sure they do, using system call 64:
http://www.menuetos.net/syscall.txt

In the interview they say they don't have proper malloc.

EDIT: they say exactly :

Currently Menuet applications have a continuous memory area, which you can resize with a system call.

Not what i'd call memory allocation, even basic...

[Leffmann]

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.

[ross]

Originally Posted by meynaf

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

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 )

I must always remember not to use it

[meynaf]

Originally Posted by Leffmann

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.

[meynaf]

Originally Posted by ross

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 ?

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

Another reason for me to prefer coding on 68030

[ross]

Originally Posted by meynaf

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

IRQ -> ipl field = level

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

Yes, this is the little oddity
But admissible to allow an NMI to always be accepted.

[plasmab]

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.

[roondar]

68000 memory access is actually no slower than the 8086. For block moving, it’s actually quite a bit faster. For reference, the 68000 also outclasses the 6502, 8080, Z80 and 6800 for memory speed

The ARM is indeed much faster, but well, what do you expect of a CPU design that’s 8 years newer (it’s from the same year as the 68030).

[plasmab]

Originally Posted by roondar

68000 memory access is actually no slower than the 8086. For block moving, it’s actually quite a bit faster. For reference, the 68000 also outclasses the 6502, 8080, Z80 and 6800 for memory speed

The ARM is indeed much faster, but well, what do you expect of a CPU design that’s 8 years newer (it’s from the same year as the 68030).

Not the 6502 it doesn’t.

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

[roondar]

Originally Posted by plasmab

Not the 6502 it doesn’t.

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.

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.

[plasmab]

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.

[meynaf]

Originally Posted by roondar

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.

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

[plasmab]

Originally Posted by meynaf

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.

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.

Plus a modem CPU pulls 128 bits per access.