meta assembler: from z80 to m68hc11. Possible? Worthwhile?

[legacy]

So I am playing with an old hc11 board, I have already ported a basic interpreter, and BUFFALO, and I have merged them into a 16KB rom.

All fine.

But I really *HaTe* the fact I can't port tools on my PA-RISC-workstation: GAS (GNU assembly) is compatible with neither the Basic11 source nor Buffalo11. Adapting them is so boring, and I need an assembly compiler which, thanks god, happens to be well written for linux-x86.

With z80 you aren't so lucky since you need wine and/or DosBOX because binaries are not for linux, and you don't have sources.

Now, gcc-11 is dead with gcc-v3.3.6, which is the last stable. gcc-v4.6 was the last. Since then they removed HC11 from the supported architectures list: You don't have gcc(1). But SDCC is still alive, still supported. It supports z80, 8051, but it doesn't support HC11.

So I wonder if I'd better write a meta assembler (recycling my lib-lexer/parser/etc? mumble?!?). It would be cute to invoke SDCC C->asm.z80, then translating the Z80 assembly code into HC11.  It makes sense because all the recent GNU-Binutils-2.2* still have support for HC11.


C code -> SDCC -> z80 assembly -> meta assembler -> hc11 assembly -> GAS-HC11 -> object -> linker -> HC11 binary



(1) I have created a gentoo's Overlay, with a super experimental (very unstable) cross-m68hc11-elf/gcc-3.3.6-r9999.ebuild
It has been set manually with a few patches of mine, and it gets emerged and installed. I still have to test it.

Code: [Select]

RedQueen ~ # gcc-config -l
 [1] hppa2.0-unknown-linux-gnu-4.1.2 *
 [2] hppa2.0-unknown-linux-gnu-4.2.4
 [3] hppa2.0-unknown-linux-gnu-4.4.7
 [4] hppa2.0-unknown-linux-gnu-4.9.3

 [5] hppa64-unknown-linux-gnu-4.9.4 *
 [6] m68hc11-elf-3.3.6--experimental *
 [7] m68k-elf-4.1.2 *
 [8] m68k-unknown-linux-gnu-4.1.2 *
 [9] mips-unknown-linux-gnu-5.3.0 *
 [10] mips64-unknown-linux-gnu-5.3.0 *
 [11] powerpc-unknown-linux-gnu-5.3.0 *

Fingers crossed. I don't expect any magic from it.

[legacy]

Code: [Select]

RedQueen # myemerge-log =cross-m68hc11-elf/gcc-3.3.6-r9999 --buildtime

real 23m16.977s
user 16m35.996s
sys 5m59.776s

Faster than a fsk 

[helius]

Binary translation is, at its simplest, a static emulation. So the problem is that with an emulator, you can have a structure that represents the state of the processor and functions that change it and do side effects. If you want to emit that statically, you could have a lot of bloat.
What you need to do is optimize the output to remove unnecessary emulation of features in ARCH1 that aren't being used. Getting it to use features of ARCH2 (the target) that aren't present in ARCH1 is more difficult.
I'm not sure there is any point in parsing asm output. asm is for humans. Might as well just decode the binary

[legacy]

Yup, I assume HC11 and Z80 are very similar. Well Z80 has 8 registers, HC11 has 1 register, but can use the internal ram as "soft registers" 

But, I don't know Z80 so well. That is the reason of this topic. I know there are skilled people here, and they know Z80 in details, and also HC11 in details.

[legacy]

oh, about resources … the board in the picture (home made) comes with

8KB of ram
16KB of ROM
512byte of iRam

 

[westfw]

GAS (GNU assembly) is compatible with neither the Basic11 source nor Buffalo11.

Can you make it compatible?  I once wrote a set of macros to implement 8085 assembly using Macro-10 (nominally, an assembler for a 36bit CPU.)  It turns out a lot of my friends have done similar things.   Macros are powerful things, and those old CPUs (up until the x86, approximately) had very simple assembly syntax.

Do you have VM capability?  You could try running FreeDos on a VM - it doesn't sound that much different than DosBox from a usage PoV, but would be faster and probably better supported.  Doesn't Motorola Freescale NXP still sell 6811 chips?  Don't they still have tools (Hmm.  DOS tools; is that what you're already using?)

Maybe it's time to flush the PA-RISC workstation?

I assume HC11 and Z80 are very similar.

Not really; Z80 is an 8080 follower.  HC11 is a (more distant) 6800 follower.  I guess you could argue that the Z80 added some 6800-like features to the 8080 architecture, but I wouldn't expect them to be easy to translate at the assembly language level.

Z80 has 8 registers, HC11 has 1 register

Z80 has 1 AC, 7 other registers, an "alternate set" of those 8 registers, two index registers, plus SP and PC.
HC11 has 2 ACs, but no other registers, plus two index registers, SP, and PC.
They handle 16bit operations quite differently.
HC11 can push 8bit registers on the stack; Z80 only puts 16bit operands on the stack.
I'm not sure what else; I mostly did only 8080 (subset of Z80), and only watched 68xx "slightly."

[ale500]

SDCC has a 68hc08 port. I would think of the HC11 as a superset of the hc08. It may be easier to modify this port to get HC11 output instead of using two completely different architectures with also to consider, different endianness !

[legacy]

DosBox

I have ported a 100% working ebuild of DosBox into the overlay of my HPPA userland. But I don't like it at all mainly because it forces me to emerge and compile a lot of stuff which I don't need and I don't want to have on my userland, e.g. SDL (it's not stable on HPPA, and it doesn't make sense to have it)

But yes, I can re-emerge DosBox

Currently I have moved DosBox on a x86/32bit workstation, which is also useful for GNAT(1), which is not existing on HPPA. The x86 workstation has GNAT, so it's fine. Its hard drive is CIFS mounted, so it can share files and projects, and it can add everything including Wine and x86 binary compatibility.

But I actually *HATE* x86, and my purpose is making my HPPA workstation completely independent from those x86 shit.

Of course, Hobby purpose, unfortunately for my job's need I can't leave the x86

at least because:

• EagleCad
• OrCad
• TinaDesign Suite (~pSPICE)
• LabView
• Xilinx ISE
• Rhinoceros

they are all x86-only binaries. No way to replace them with open source.
Gameover: I still need a x86 machine (even if I HATE it)

Doesn't Motorola Freescale NXP still sell 6811 chips? 

It's EOL, since a while

Don't they still have tools (Hmm.  DOS tools; is that what you're already using?)

Licenses for ImageCraft Compiler for 68HC11 are still available: 250 USD, x86 Windows XP/32bit.
Cosmic Software compiler for HC11 is also a good candidate, and still available too. ~400 USD

But it's not the point. Because I HATE x86 

Maybe it's time to flush the PA-RISC workstation?

Never! I would trash away the x86 workstation instead 
(well, I would put it on ebay for a few quid, in order to buy new gears, e.g. PCI-sATA adapter, etc, for my HPPA workstation)

I'm not sure what else; I mostly did only 8080 (subset of Z80), and only watched 68xx "slightly."

I have been working with RISC for years, and used m68hc11 when I was on high school. I need a full immersion refresh, back to my 90s manuals, but I am still very busy with the Arise-v2 project, which is pure RISC design. And I have written both the assembly compiler and the simulator, going to complete the high level language compiler (it's not a C compiler, it's a new language similar to the C language), so I don't have the x86-legacy problem, since I can compile my tools for HPPA (currently they are HPPA2 binaries).




(1) GNAT is needed by RTL simulators. fpga, cpld. etc.
I don't like Mentor and iSIM.

[legacy]

SDCC has a 68hc08 port. I would think of the HC11 as a superset of the hc08.

oh, interesting

[legacy]

Code: [Select]

RedQueen # m68hc11-elf-gcc -v
languages=c
gcc version 3.3.6-r9 build-20170114

Compiled by hppa2.0-gcc v4.1.2, not a good choice, but more recents compilers fail in recompiling gcc v3.3.*
it uses gcc-core sources from GNU, 2010 patches from debian, and other patches.

It seems to be working   

More tests and test-cases are strictly needed before I can really trust the cross-compiler.

Code: [Select]

RedQueen # myemerge-log --query m68hc11

m68hc11-elf-addr2line                 m68hc11-elf-emerge                    m68hc11-elf-gprof                     m68hc11-elf-pkg-config
m68hc11-elf-ar                        m68hc11-elf-fix-root                  m68hc11-elf-ld                        m68hc11-elf-ranlib
m68hc11-elf-as                        m68hc11-elf-gcc                       m68hc11-elf-ld.bfd                    m68hc11-elf-readelf
m68hc11-elf-c++filt                   m68hc11-elf-gcc-3.3.6-9               m68hc11-elf-nm                        m68hc11-elf-size
m68hc11-elf-cpp                       m68hc11-elf-gccbug                    m68hc11-elf-objcopy                   m68hc11-elf-strings
m68hc11-elf-elfedit                   m68hc11-elf-gcov                      m68hc11-elf-objdump                   m68hc11-elf-strip


LOL, an interesting odd clue: m68hc11-elf-emerge (WTF?) does not make sense since m68hc11 can't run linux 

I wonder HOW it has been emerged, with which profile (probably m68k?)… there is for sure something wrong with the ebuld, but I don't have the time to dig it out.

gentoo goes very complex about toolchain, especially because it assumes you want to crosscompile for linux

[legacy]

SDCC v2.5.6
target[]={ mcs51, gbz80, z80, avr, ds390, pic16, pic14, TININative, xa51, ds400, hc08 }


Someone knows all the differences between hc08 and hc11 in details ?

[legacy]

hc08 datasheet (MC68HC908JB8) I am going to upload it into my Kindle ebook and pdf reader, I will read it later 

[eugenenine]

LOL, an interesting odd clue: m68hc11-elf-emerge does not make sense since m68hc11 can't run linux 

That depends on how you define Linux.  If you lump BSD in as 'unixish' then I believe there is/was a retrobsd port.

[legacy]

That depends on how you define Linux.

Linux needs at least a CPU with
- 32bit address space, the kernel happens to be huge (>>4MB)
- MMU

Ok, you could in the theory run linux on devices which don't have a MMU (uclinux is the MMU-less port), but … a 68xx comes with 16bit addresses, and you can't put linux in 64KB!

If you lump BSD in as 'unixish' then I believe there is/was a retrobsd port.

XINU 'might' be stripped for 6811 



The error above comes from how gentoo defines a cross-tool. Usually it assumes you want to cross-compile from arch1/linux to arch2/linux, e.g. from x86-linux, to hppa-linux.

I have sorted out. I had forgotten to add a few lines in my ebuild in order to push things into the right way, and emerge had assumed the full profile instead of a embedded/barebone

[Benta]

The closest relative to the 68HC11 is the 6801.
The 68HC08 is an improved 6805.

[chickenHeadKnob]

The closest relative to the 68HC11 is the 6801.
The 68HC08 is an improved 6805.

Back when dinosaurs roamed the earth and I had a full head of golden hair both the 6809 and 68hc11 were popular with the FORTH hobbyists. I didn't play with them then so may be mis-remembering. I thought the 68hc11 was a follow on to the 6809, anyway I am certain there must be ANS FORTH copies floating around. The good thing about FORTH is the self hosted development with tethered  debugging and small memory footprint. Also FORTH comes with its own primitive assembler. (usually)

Okay scratch that idea, all of the FORTH links I followed require a PC to do the initial hosting and you already have a basic monitor going.

[legacy]

Back when dinosaurs roamed the earth and I had a full head of golden hair

My HC11 manual says "printed in 1989", but I happened to meet the first chip in 1995-97, when I was on high school.

[Benta]

I thought the 68hc11 was a follow on to the 6809

No, the 68HC11 grew out of the 6801.
The 6809 was an extremely advanced CPU, probably the highest-end 8-bit ever built. But as the 68K came out at approximately the same time, it's moot.

[westfw]

Does anyone have a "lineage" of the 68xx processors?  My impression is that the 6800 begat 6809 as an "enhanced microprocessor" and 6805 as a "microcontroller", and then 6811 is the microcontroller version of the 6809, while 6808 grew out of the 6805 branch of the tree.  But I wasn't paying attention to either the technicalities or the marketing...

While the 6800/6809 gained some attention in the personal computer space, the Motorola microcontrollers were pretty much unobtainable to hobbyists, and didn't generate much interest until the 6811 versions with EEPROM came along and permitted small-ish hobby boards that could be used without high voltage EPROM burners and UV erasers. (thanks to the 68xx von Neumann architecture, you could use the EEPROM for small machine-language programs as well as data (like basic source code.)   A 6811 with some EEPROM and Buffalo (monitor/debugger) in the ROM/EPROM made for a pretty good educational system, compared the the alternatives at the time.  Even though it was still relatively expensive and hard to buy...)

[legacy]

The 6809 was an extremely advanced CPU

Oh, I don't have a MC6809 board, and I have no interest in doing it, but I can port gcc-6809 into gentoo-overlay. I just need to recycle a few lines from the ebuild I have created for MC68HC11. An experimental branch exists for gcc-v4.3.* and it specifically supports 6809, so I can extract patches and apply them to the builder.

Using gcc-core, I will rename it as

=cross-m6809-elf/gcc-v4.3.3-r2014
=cross-m6809-elf/gcc-v4.3.6-r2014

[ale500]

the 6809 port of gcc is not that easy. Look for lwtools and the patch for 4.6.4 here:

http://perso.b2b2c.ca/~sarrazip/dev/cmoc.html

I still think that porting sdcc to the 68hc11 may be the best

[Benta]

Does anyone have a "lineage" of the 68xx processors?

The 6800, 6802, 6808 etc. all had the same CPU, the difference was integration level.
The 6801 also had the 6800 CPU, but IIRC a couple of new instructions.

Motorola realized that the 6800 series was far too expensive for the low end controller market, and created the 6805, with similar architecture, but very much simplified (eg, less registers and addressing modes, no stack operations).

68HC11 was made on a clean sheet of paper, rolling all the gathered experiences into one design and had a lot of clever solutions, for instance the invention of XIRQ instead of NMI, which always was a design problem. In some features it was simpler than the 6800, in others more advanced.

The 6809 is a special case. It was built on the 6800, but had a lot of very advanced features in the architecture. It was the ultimate 8-bit CPU.

There is no real connection between 6809 and 68HC11 except a common ancestor.

[Kalvin]

That depends on how you define Linux.

Linux needs at least a CPU with
- 32bit address space, the kernel happens to be huge (>>4MB)
- MMU

You are too spoiled. You can run Linux on a ATMega1284p
http://hackaday.com/2012/03/28/building-the-worst-linux-pc-ever/

[legacy]

You are too spoiled. You can run Linux on a ATMega1284p

Linux on an ARM emulator built on ATMega?
30 minutes to bootstrap?

Yes, it's exactly the machine I don't want to have 

[legacy]

68HC11 ... In some features it was simpler than the 6800, in others more advanced

is there a paper which summarize the these differences in details?
It would be useful to understand how dig I have to go with SDCC-08 in order to adapt it for HC11.
(if it's possible, and if it makes sense)

[legacy]

Look for lwtools and the patch for 4.6.4

D'oh, it needs a new branch in the overlay. Things go more complex