Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #54979 > unrolled thread

How easy to port to this 68000 variant-ish?

Back to article view | Back to comp.lang.forth

Contents

  How easy to port to this 68000 variant-ish? jacko <jackokring@gmail.com> - 2017-02-18 13:44 -0800
    Re: How easy to port to this 68000 variant-ish? Paul Rubin <no.email@nospam.invalid> - 2017-02-18 16:05 -0800
      Re: How easy to port to this 68000 variant-ish? jacko <jackokring@gmail.com> - 2017-02-18 16:15 -0800
        Re: How easy to port to this 68000 variant-ish? Paul Rubin <no.email@nospam.invalid> - 2017-02-18 19:50 -0800
          Re: How easy to port to this 68000 variant-ish? jacko <jackokring@gmail.com> - 2017-02-18 20:17 -0800
    Re: How easy to port to this 68000 variant-ish? hughaguilar96@gmail.com - 2017-02-18 17:41 -0800
      Re: How easy to port to this 68000 variant-ish? jacko <jackokring@gmail.com> - 2017-02-18 19:29 -0800

#54979 — How easy to port to this 68000 variant-ish?

So

https://dl.dropboxusercontent.com/u/1615413/Own%20Work/68k2.pdf

And some of the instructions have been renumbered in opcode, and some are missing for good, and it's a 64 bit variant, and it's an idea in progress. Some new opcodes have been added. There's some familiarity to the layout of the opcodes to make machine code morphing of possible code segments into 68k2 code. The design is open, and 3 addressing modes have yet to be designed.

Jacko

[toc] | [next] | [standalone]

#54982

jacko <jackokring@gmail.com> writes:
> https://dl.dropboxusercontent.com/u/1615413/Own%20Work/68k2.pdf

Is this something you're developing yourself?  Why?  The 68000 was great
in its day, but that approach is now rather old-fashioned.  Do not not
like RISC-V?

What do you mean about "how easy to port"?  You mean run Forth on it?
Get a Forth-based toolchain going?  Or what?

Maybe it's because I'm not conversant with FPGA's but I'd say start with
a software emulation to get the basic tools working.  That will also
give you something to test your FPGA against.

[toc] | [prev] | [next] | [standalone]

#54985

> Is this something you're developing yourself?  Why?  The 68000 was great
> in its day, but that approach is now rather old-fashioned.  Do not not
> like RISC-V?

Yes, OCD ... :D

> What do you mean about "how easy to port"?  You mean run Forth on it?
> Get a Forth-based toolchain going?  Or what?

It has some of the instructions, some are slightly mangled, but the majority of code would have quite a lot of 1 to 1 machine code mapping.

> Maybe it's because I'm not conversant with FPGA's but I'd say start with
> a software emulation to get the basic tools working.  That will also
> give you something to test your FPGA against.

The software emulation may come later. The main reason I think is that there is much 68k software available. The boot strap of a whole OS would be comparatively simple.

As to why not RISC-V? Well, it's not about hating RISC-V. It's about familiarity, and I think the differences will be of use in instruction set experimentation. At the moment it's a vapour design effort. For fun. But so far I've had some good insights into compact CISCy instruction sets for 64 bit. It's an CISC -> uOP interest I have.

Jacko

[toc] | [prev] | [next] | [standalone]

#54991

jacko <jackokring@gmail.com> writes:
> majority of code would have quite a lot of 1 to 1 machine code mapping.

You mean you want to run 68000 binaries on the new cpu after some
machine translation?  It's not impossible, binary translators are
written all the time, but if you want a 32-bit m68k why not use one?
Don't they still make them?

> The boot strap of a whole OS would be comparatively simple.

I doubt this ;-)

[toc] | [prev] | [next] | [standalone]

#54992

A 64 bit 68000, with some undoing of some of the 68040 addressing mode madness, and then putting some more prime modes back in ...

A subroutine jump twice indirect with auto increment?

[toc] | [prev] | [next] | [standalone]

#54988

On Saturday, February 18, 2017 at 2:44:06 PM UTC-7, jacko wrote:
> So
> 
> https://dl.dropboxusercontent.com/u/1615413/Own%20Work/68k2.pdf
> 
> And some of the instructions have been renumbered in opcode, and some are missing for good, and it's a 64 bit variant, and it's an idea in progress. Some new opcodes have been added. There's some familiarity to the layout of the opcodes to make machine code morphing of possible code segments into 68k2 code. The design is open, and 3 addressing modes have yet to be designed.
> 
> Jacko

Michael Barry is designing his 65m32 that appears to be 32-bit processor with 6502 inspiration --- you could trade ideas, as you both seem to be interested in upgrading old processors --- I would consider the 65m32 to be more likely to be useful, because FPGAs have internal RAM which would make all of those zero-page pointers fast, so it would be like having a lot of registers.

What is you opinion of the ColdFire?

Have you ever written an assembler for the MC68000? I read that the opcodes are mostly designed so the parts of the instruction correspond to bit ranges in the opcode, so the opcode can be constructed by ORing together the parts --- but that there are a lot of annoying exceptions that have to be special-cased --- I don't have any experience with it though.

[toc] | [prev] | [next] | [standalone]

#54990

> Michael Barry is designing his 65m32 that appears to be 32-bit processor with 6502 inspiration --- you could trade ideas, as you both seem to be interested in upgrading old processors --- I would consider the 65m32 to be more likely to be useful, because FPGAs have internal RAM which would make all of those zero-page pointers fast, so it would be like having a lot of registers.

> What is you opinion of the ColdFire?

It has removed a lot of the instructions which occupy the follow on size from .B, .W, .L and then ... a lot of poo where .Q should be. I removed all those, and went for the quaf word extension. I also dropped the MOVE.B in favour of MOVE.Q, and a better consistency to bits 13 and 12 as a size field, when 14 and 15 are 00. So yes, interesting, but not what I was after with the design fun. I didn't mind relocating MOVE.W and MOVE.L as I changed the source and destination in the opcodes anyhow, to better fit with detecting a consistent #immediate destination.

> Have you ever written an assembler for the MC68000? I read that the opcodes are mostly designed so the parts of the instruction correspond to bit ranges in the opcode, so the opcode can be constructed by ORing together the parts --- but that there are a lot of annoying exceptions that have to be special-cased --- I don't have any experience with it though.

The annoying exceptions are the ones that go where the 64 bit extension should have gone, I put there. I might add a few of the missing instructions to an extended double word instruction format. ut no I never wrote a 68000 assembler. I did see some source code for one, and I have used one.

Jacko

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web