Hi MSX users!
I use ASCII C compiler: IMHO one of the main limitations is the label length limit to 6 chars.
Compilation is performed in basically 5 steps:

1) CF uses .C source to produce an intermediate .TCO file which seems to be a "human readable" description of what the code should do, in this file labels are still complete (I read cf should support up to 16 chars labels which is not so much compared to modern compilers but much better compared to "only" 6 chars)

2) FPC check for parameters correctness

3) CG uses .TCO file to generate a .MAC file which can be assembled with M80. Here labels are truncated to 6 chars

4) M80 uses .MAC to generate a .REL file

5) L80 links .REL to give final .COM executable.

I imagine that CF, CG, M80 and L80 sources are not available... so here are my questions:

1) has anybody tried to disassemble/reverse engineer one or more of this programs?

2) has anybody documentation/info about .TCO file format?

3) is anybody interested in the development of an enhanced version of ASCII C compiler?
(IMHO the possibility to produce debuggable code would be very interesting for developers)
Thanks for your attention
MicroTech

Hi!
My question is .. for what ASCII C compiler? ... i suppose that is for compiling directly in a MSX, right?
Because if you are using PC .. i recommend you SDCC.

Hi Nerlaska!

> My question is .. for what ASCII C compiler? ...

Pro:
1) produce very efficient code
2) basic and extended libraries already available and working
3) produce .MAC files which you can look at, modify, study, optimize as you wish
4) does not use "slow" registers IX and IY which can be used for custom functions (probably an inheritance of 8080 cpu)

> i suppose that is for compiling directly in a MSX, right?

5) for compiling directly in a MSX, right!

Call me "anachronistic" but I feel that a machine is "cool" if applications can be developped on the target itself.

> Because if you are using PC .. i recommend you SDCC.

I read you are going to develop an SDCC based SDK for MSX/SymbOS, seems very interesting and cool and I'm very interested in this kind of stuff.
Why should this SDK be "bound" to SymbOS? Can SymbOS provide debugging facilities?

Well ...
I use SDCC from last year. My first development have been Monster Hunter. I sure you that working in PC for MSX is an incredible compiler.
1) Produce efficient code
2) i have done my own basic and extended libraries (pt3, afx, psg, scc, music module, fmpac, joystick, mouse, bios, vdp, disk, tape, etc.)
3) SDCC produces from C the .ASM files that you can modify.
4) Well. Uses IX and IY registers :-)
5) And yes, not compile in MSX. And i'm with you. I want to compile inside of a MSX. I'm "anachronistic" too!!

About Symbos SDK. Well. I think MSX needs an OS with GUI for the new hardware developed (GFX9000 & Network & RAM expansions) and i can say that SYMBOS is really a fantastic work and a very good OS. Prodatron have made a very good work!
I want to arrive to my home and turn on my MSX and develope, chat, explore, etc. Then i want to help Prodatron building apps for Symbos and making better his OS for the MSX Machines.
For it, i think a C SDK is very good way. I have done the Resource Compiler and the SymbosMake for compiling all C files and creates Symbos EXE.
It's easy, code is like Win32 programming, really make an application in this way is very simple.
About debugging .. i think we could try something for adding breakpoints, etc. but i don't know really if it's possible with Z80.

Quote:

Well ... I use SDCC from last year.

[OT]
Hi, nerlaska, can you send me your email at spambin at tiscalinet dot it? i'm interested about sdcc symbos sdk.

i'm working in it .. and i need to solve some bugs .. i have started with it this last week.
When i had more advanced .. i'm sure Prodatron will upload into his web.

Quote:

5) And yes, not compile in MSX. And i'm with you. I want to compile inside of a MSX. I'm "anachronistic" too!!

Well... I think that developping on a PC, MSX loses some of its "didactical" purpouses... and lot of its "frustrating" feeling
If OCM will really have a "100MHz" T80 than native development is still doable.
I "dream" a OCM with a "TurboC style" SDK where you can edit, compile, run, debug with symbols and breaks So I can develop anywhere without having to bring with me a portable PC.

Quote:

About debugging .. i think we could try something for adding breakpoints, etc. but i don't know really if it's possible with Z80.

I'm not expert about "monitor" programs so maybe I'm saying "fools":
1) software breakpoint is possible when a program is running in ram so you can place a processor specific instruction (on Z80 a RST instruction) in the "place" where you want your code should break
2) because RST will restart in page 0 then some "strategically placed code" should be set there
3) an application (a SymbOS .EXE) should come with additional informations, provided by the compiler, something like an ELF format so each address in the .EXE could be located in the correspondant source file

By your experience: is it possible to port SDCC to MSX?

So does this mean that sdcc is the only way to bypass the limits of ascii c compiler?

The cp/m version of HiTech C is available free of charge and you can find some useful msxdos2 tools and libraries on MSX Banzai!. See also the C compiler comparison threads on MRC.

If the program CG from Ascii C keeps the original source as comments, you might be able to reconstruct the full identifiers and combine the code generator from ascii with the assembler and linker from HiTech. You would have to convert the Ascii c-libraries as well though. Expect to invests loads of time to get this to work.

I think SDCC is simply to big to port to MSX, even if you omit all code for other other processors than Z80.

Then cross assembler use is the only way to bypass that limit.However can't s someone port sdcc to uzix or symbos?would not that be an option?

@arnold_m:
Thanks for your offer but IMHO ASCII C produces faster code and is completely redefinable.
(it also includes sources of runtime library so I could even change the internal 8 and 16 bit mutiply routines to use R800's MUL instruction, getting better performance)

@nikodr:
If SDCC is "too big" for running on an MSX, then uzix or symbos is not relevant: probably SDCC would require too many resources MSX cannot provide with the easy a PC can...