Borland Turbo Modula-2 M-Code?

89 views
Skip to first unread message

Josef Moellers

unread,
Nov 26, 2018, 4:46:18 AM11/26/18
to
Hi,

I have recently revived an old SB180FX computer (from Steve Ciarcia's
BYTE articles). Among other things, I have a Borland Modula-2 compiler
and I was curious what the MCD files look inside.
Does anyone have any information on this?

So far, I have found out that
8dH is a LIB (Load Immediate Byte)
8eH is a LIW (Load Immediate Word)
8fH is a LID (Load Immediate Double)
90H-9fH are LIn (Load Immediate n, where n is a 4-bit quantity)
FnH seems to be some function call

Does anyone have more information?

Josef

Chris Burrows

unread,
Nov 26, 2018, 7:59:11 AM11/26/18
to
The Turbo Modula-2 manual says that the M-Code used is a variant of the M-Code used by Lilith. If you haven't already got it, you can download ETH Report Nr 40 - The Personal Computer Lilith. Apr 1981. N. Wirth "The Yellow Report" which includes the M-Code instruction set and the source code of a sample M-Code interpreter from my site:

http://www.cfbsoftware.com/modula2

The Z80 M-Code interpreter is located at the bottom of the TPA at Address 100H and is about 4.5K bytes. You could try disassembling that and comparing the result with the source code in the report perhaps?

Chris Burrows
CFB Software

Josef Moellers

unread,
Nov 26, 2018, 8:21:44 AM11/26/18
to
Thanks.

On 26.11.18 13:59, Chris Burrows wrote:
> The Turbo Modula-2 manual says that the M-Code used is a variant of the M-Code used by Lilith. If you haven't already got it, you can download ETH Report Nr 40 - The Personal Computer Lilith. Apr 1981. N. Wirth "The Yellow Report" which includes the M-Code instruction set and the source code of a sample M-Code interpreter from my site:
>
> http://www.cfbsoftware.com/modula2

Yes, I've seen that, but the numbers do not seem to match.

> The Z80 M-Code interpreter is located at the bottom of the TPA at Address 100H and is about 4.5K bytes. You could try disassembling that and comparing the result with the source code in the report perhaps?

I'm good at disassembling ;-)
I assume that most of the compiler itself is running on top of the mcode
virtual machine, judging from these filenames: COMPILE.MCD, GENZ80.MCD
I'll see what I can find.

Thanks again.

Josef

Chris Burrows

unread,
Nov 26, 2018, 3:59:18 PM11/26/18
to
On Monday, November 26, 2018 at 11:51:44 PM UTC+10:30, Josef Moellers wrote:
> I assume that most of the compiler itself is running on top of the mcode
> virtual machine, judging from these filenames: COMPILE.MCD, GENZ80.MCD
> I'll see what I can find.
>

That is correct. COMPILE is the compiler and GENZ80 is the native code generator. Refer to Page 258 in the manual, 'Modules in Memory Management' for more information. If you don't already have a copy you can download it from:

www.cpcwiki.eu/imgs/6/64/Borland_Turbo_Modula_2.pdf

I'd be interested to hear about any progress that you make.

Chris.

Josef Moellers

unread,
Nov 28, 2018, 4:14:55 AM11/28/18
to
1st "Erfolgserlebnis" (sense of achievement):

1) The first 512 bytes in the m2.com are a jump table, unusually coded
as first 256 low bytes then 256 high bytes.
2) while most instructions have no arguments, some instructions do 'ave 'em.
3) DE is the m-code program-counter.
4) m2.com is mainly running m-code.

Having found the jump-table, I can now see what each instruction does.

NB I've used a combination of passive and active analysis:
A) a (mostly) dis-assembled m2.com (using a self-written disassembler
which follows jumps and calls and knows a dead-end when it sees one ;-)
and also allows me to specify entry-points for those cases where the
address is calculated.
B) Using Perl/Expect and a small helper to send/receive through the
serial line, I used a debugger to step through m2.com on my SB180FX.
This showed a "JP (HL)" at more or less regular intervals, the value of
the accumulator was the currently decoded instruction.

Josef
Reply all
Reply to author
Forward
0 new messages