TOS 2.06 improving - task for good C coder

News,announcements,programming,fixes,game patches & discussions.

Moderator: Petari

User avatar
Smonson
Posts: 165
Joined: Sat Oct 28, 2017 10:21 am

Re: TOS 2.06 improving - task for good C coder

Post by Smonson » Thu Jun 28, 2018 11:13 am

Petari wrote:
Thu Jun 28, 2018 10:54 am
As said, I'm not good with C. So, you mean that should change something at ASM parts syntax ? Or you mean that not use 68000 ASM at all ?
I don't think that it can be done without serious speed problems and lot of time. Early stage - HW init, test, BIOS is done in ASM. Then interrupt handlers, because they are time critical. If it is just to change sysntax of included ASM code, should be not that hard.
Other way, what I think is more realistic is to use some established C compiler for Atari. That will not produce so efficient code as some modern, but it will work after not too much corrections, I guess.
No, no, nothing like that. It's only the assembler syntax. Traditional assembler syntax for Atari and others (known as Motorola syntax) uses register names without a prefix, so there is a potential name conflict between register names and labels.

But gcc uses a percent sign on registers (AT&T syntax) to avoid this problem. However, due to many Atari programs using the older form, the m68k-atari-mint version of gcc has been modified to use the old assembler syntax. And new Atari programs written in C tend to continue using the old syntax as well, perpetuating the problem.

It is a very minor point of difference, but the end result is that a special version of GCC, specific to the Atari ST, is needed. If AT&T syntax is used for inline assembler, you can just use gcc straight out of the box.

Petari
Software Moderator
Software Moderator
Posts: 560
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS 2.06 improving - task for good C coder

Post by Petari » Thu Jun 28, 2018 11:17 am

troed wrote:
Thu Jun 28, 2018 9:34 am
I agree that if we're breaking binary compatibility (not so important for TOS 2.06 I think) it would be nice to have an updated toolchain. However, signed 32 bit variables should be enough to get full FAT16 support.
(I don't know when I will have time to actually make the modifications. The C code is fully understandable though so the task of making the actual edits should be quite simple as long as all the correct points to change can be found)
Otto is not interested for compiling it with anything other than that old Alcyon (or its clone). And of course said, that we need to use emutos :lol:

There are some 32-bit variables, most is 16-bit. If you just expand 16-bit to 32-bit will not solve problem, and you will make another: breaking variable map in RAM, since will need more space. And even when correct all addresses after expansions, there is another problem: AES/Desktop must go higher, so will need to correct all it's variables - that's too bad.
To explain: ASM code tst.w d5 , blt somewhere will jump somewhere if d5 is negative. So, area $8000-$FFFF . If you expand to 32-bit you can not use any tst command. Need to use cmp.l #$10000 (unsigned 16 bit value is to test actually)- for check is over 16-bit range. But actually is better to stay at 16-bits and compare with $FE00 - since that's real max cluster count. So, 16-bit variable is OK, just need to change C code. Maybe because Alcyon, should really use 32-bit one, but this is only one case. And we don't know will some concrete compare with constant work well - if staying at 16-bits. There are other, different ones. I changed over 300 places in code. With C should be much less, but I think that still may be over 150 .
This will not work well without serious testing and tracing for concrete error.
I don't know, maybe to do same as I did with 1.04 . Proper disassembling is hardest part, that may took 5-6 full days. Then to do same changes as in 1.04, but it will be not easy since generated code is not same. While source is probably pretty much same - according to same partition size and count limitations. Binary compatibility is actually not important. I changed some code pretty much. Addresses will shift a lot, especially when using optimizations - not problem too, except couple very stupid SW, what assumes that some rutines are always on same address in TOS - so work only with 1 specific TOS v., language must be same too. STOS will be not problem too - my fixer uses not address tables of ROM versions.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Petari
Software Moderator
Software Moderator
Posts: 560
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS 2.06 improving - task for good C coder

Post by Petari » Thu Jun 28, 2018 11:21 am

Smonson wrote:
Thu Jun 28, 2018 11:13 am
...
No, no, nothing like that. It's only the assembler syntax. Traditional assembler syntax for Atari and others (known as Motorola syntax) uses register names without a prefix, so there is a potential name conflict between register names and labels.
But gcc uses a percent sign on registers (AT&T syntax) to avoid this problem. However, due to many Atari programs using the older form, the m68k-atari-mint version of gcc has been modified to use the old assembler syntax. And new Atari programs written in C tend to continue using the old syntax as well, perpetuating the problem.
It is a very minor point of difference, but the end result is that a special version of GCC, specific to the Atari ST, is needed. If AT&T syntax is used for inline assembler, you can just use gcc straight out of the box.
OK, I see. Question is, will it be enough. I think that there will be other problems. And we actually have no any concrete experience. I seen only that Otto said that it produced not working code. Really don't know what exact v. of GCC he used.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Petari
Software Moderator
Software Moderator
Posts: 560
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS 2.06 improving - task for good C coder

Post by Petari » Fri Jun 29, 2018 7:20 am

I have some more dilemmas/questions about using generic GCC . So, it has built in 68000 support. What about TOS support ? There must be (added) library for that - like trap calls .

I installed Lattice C 5.60 - what is considered as best for Ataris - by Hisoft. Pretty similar to Devpac, btw. Yeah, that's real IDE - no need to bother with some COMMAND interpreter and like . But I will need some time to get into, so will do for begin some really trivial things - well, probably just will try to test code generation with some simple couple line programs. Of course with accent about signed/unsigned variables.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

Petari
Software Moderator
Software Moderator
Posts: 560
Joined: Tue Nov 28, 2017 1:32 pm

Re: TOS 2.06 improving - task for good C coder

Post by Petari » Mon Jul 02, 2018 1:21 pm

Just to add here that that tos306de source package by Otto Thorsten is simply done in not Atari friendly way. It needs Gemini because there are long filenames. It needs usage of backslash, what may be problem to enter with some SW, config. All what he does is saying: that and that should work. Sorry, that word self never made anything working. And what was the whole purpose: just to recreate exact binary copy of TOS 2.06, 3.06 . Ehm. And maybe to spit on TOS and advertise EmuTOS. Well, good ware does not need advertising, even if must pay for it.
There is 2 kind of people: one thinking about moving to Mars after here becomes too bad, the others thinking about how to keep this planet habitable.

User avatar
Darklord
Posts: 36
Joined: Wed Sep 20, 2017 1:41 pm

Re: TOS 2.06 improving - task for good C coder

Post by Darklord » Fri Jul 06, 2018 3:10 pm

I have an English version of TOS v3.06, adapted for the Pak 68/3 board.

Holger Zimmerman was kind enough to get it ready, English translation and
all, for me when I was installing the Pak board in my STacy.

He's pakman (correct spelling?) on either Atari Age or Atari Forum. He's not
always easy to get in contact with but he knows his stuff in and out.

HTHs.
Welcome To DarkForce! www.darkforce.org "The Fuji Lives.!"
Atari SW/HW based BBS-Telnet:darkforce-bbs.dyndns.org 520

Post Reply