ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
this is thhe code generated by the compiler
with -mt switch
That's annoying.
So to get tiny model to build correctly, you'll need to do something different in the startup code, which IIUC is your call.asm
I don't recall tasm well enough to both guess what you did and extrapolate to what to change. Post your call.asm and I'll have a better idea what to fix to accomplish one or both of two things (or you could read tasm documentation to figure this out yourself):
1) Use a group directive to define DGROUP as all of the segments used by tcc.
2) Make it clear to the linker that the entry point is at offset 0x100, so you can use both -mt for the compiler and /t for the linker to get a normal .com file.
Last edited by johnsfine; 10-01-2009 at 09:47 PM..
I don't think that is consistent the disassembly you posted earlier, so you are posting confusing information.
Quote:
1 whats a group directive?
It is a line that goes in the .asm file and defines the group named DGROUP. The syntax of the line is
DGROUP group list of segments in sequence
But I don't recall enough about tasm/tcc to know what the segments are named nor whether they all need to be pre declared in the .asm file before including them in the group directive.
I found an tiny model example online example online
DGROUP GROUP _TEXT,_DATA,_BSS
but I'm not sure that fits your environment.
In the tlink documentation you posted earlier, it mentioned a switch /m
If you use tlink with that switch it creates a .map file. One of the things in the .map file is info on all the segments, which would be enough to remind me what would be needed in the group line.
Quote:
Originally Posted by smeezekitty
setvector(0x1C, (unsigned long)clock_hook);
I don't know how clock_hook is defined. But I doubt that cast to unsigned long is the correct cast to create the right far pointer to the code.
Quote:
and the disasm of the functions:
Still looks right to me. So I think setvector is defined correctly but used incorrectly (or clock_hook is defined wrong, or you don't enable the clock interrupt correctly, or something like that).
Last edited by johnsfine; 10-01-2009 at 09:47 PM..
That is what I wanted to see. It confirms my guess that the segment names are _TEXT, _DATA and _BSS, so my suggested DGROUP line (in my previous post) is correct.
So adding that line to the .asm file may make the link work correctly with tiny memory model (the -mt on the tcc line) or maybe tasm won't like that line because the .asm file containing doesn't declare data or bss. In that case, my best guess would be to replace the line:
Code:
.CODE
with all these lines
Code:
.CODE
.DATA
.BSS
DGROUP GROUP _TEXT,_DATA,_BSS
.CODE
But remember, I haven't done this stuff myself in over ten years and even then I didn't use tasm much (I used masm and nasm).
You can leave the ,_BSS off the end of that line for now and see how that works.
That detail needs to be fixed for uninitialized global and static variables to work right. But for now you are trying to get initialized data to work and that doesn't need bss.
Distribution: Damn Small Linux, KateOs, M$ Ickdows Vista, My own OS
Posts: 1,233
Thanked: 59
Original Poster
heres what the compiler generates--its very odd:
Code:
_TEXT ends
DGROUP group _DATA,_BSS
assume cs:_TEXT,ds:DGROUP
_DATA segment word public 'DATA'
d@ label byte
d@w label word
_DATA ends
_BSS segment word public 'BSS'
b@ label byte
b@w label word
_BSS ends
_DATA segment word public 'DATA'
db 4 dup (?)
_DATA ends
_TEXT segment byte public 'CODE'
I expect DGROUP@ is just another name for DGROUP, so it could be defined the same way as DGROUP
DGROUP& GROUP _TEXT,_DATA,_BSS
but I'm not sure.
You found where the compiler output uses DGROUP. Can you find where it uses DGROUP@
That might tell me what DGROUP@ is really supposed to be.
Quote:
Originally Posted by smeezekitty
heres what the compiler generates--its very odd:
Code:
_TEXT ends
DGROUP group _DATA,_BSS
assume cs:_TEXT,ds:DGROUP
That is not at all odd for "small" memory model. That is what small memory model should look like. It is odd for tiny memory model.
There are multiple ways to do the same segment declaration. In your asm code you used the line
.CODE
That is almost the same meaning as
_TEXT segment byte public 'CODE'
except that when you do it that longer way you also need to balance it with a later
_TEXT ends
Quote:
Originally Posted by smeezekitty
is it possable to move the data segment or data segment pointer
so it finds the data?
Yes. That would be "small" memory model.
For tiny memory model, your startup code does this
mov ax,cs
mov ss,ax
mov ds,ax
For small memory model, it would do this
mov ax,cs
add ax, SOMETHING
mov ss,ax
mov ds,ax
But I'm not sure in this tool chain what you could put in place of that SOMETHING that would end up with the right number there after linking and running exetobin. My first guess would be DGROUP. The value you actually want is not equal to DGROUP, so in an .exe file (where the loader would fix that instruction to have the correct value of DGROUP) using add ax,DGROUP would be wrong. But it is likely that exetobin will get that usage of DGROUP "wrong" in exactly the right way to be the value you actually want.
But I think you are almost there with tiny model and you may find tiny model less confusing for later complex operations.
I've been trying to follow this conversation guys. I was too using a lot tc and masm about 15 years ago and the only thing I remember very well is that the segmented memory model was confusing and prompt to bug-writing. Fortunatly I found very valuable doc at the time from the tasm manual even if I was using masm. If I may suggest one thing, getting and reading the online copy, mainly the stuff about memory layout, could be very helpfull for you.
Distribution: Damn Small Linux, KateOs, M$ Ickdows Vista, My own OS
Posts: 1,233
Thanked: 59
Original Poster
it only uses DGROUP@ in tiny model
Code:
mov bp,cs:DGROUP@
mov ds,bp
mov bp,sp
and
Code:
db '%s [%d]-'
db 0
db 'w+'
db 0
db 'w'
db 0
db 'r'
db 0
db 'a'
db 0
db 'panic::'
db 0
db 'Hey!'
db 0
_DATA ends
_TEXT segment byte public 'CODE'
extrn DGROUP@:word
_TEXT ends
Distribution: Damn Small Linux, KateOs, M$ Ickdows Vista, My own OS
Posts: 1,233
Thanked: 59
Original Poster
Quote:
Originally Posted by manu-tm
I've been trying to follow this conversation guys. I was too using a lot tc and masm about 15 years ago and the only thing I remember very well is that the segmented memory model was confusing and prompt to bug-writing. Fortunatly I found very valuable doc at the time from the tasm manual even if I was using masm. If I may suggest one thing, getting and reading the online copy, mainly the stuff about memory layout, could be very helpfull for you.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
