P
Paul
What is still a text segment?
All memory and everything that ever existed in the universe, is a text
segment?
What is still a text segment?
All memory and everything that ever existed in the universe, is a text
segment?
H
hanukas
..data and .text are both directives to the assembler. .data tells the
assembler that the upcoming section is considered data. .text tells
the assembler that the upcoming section is considered assembly
language instructions.
What's your problem with this? Something that you don't understand?
P
Paul
My problem is that you are talking complete and utter shite.
A NON SEGMENTED MEMORY MODEL DOES NOT HAVE A TEXT
SEGMENT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
please get this into your thick skull and stop copying the idiot Leigh.
H
hanukas
Text segment is a segment of source code which contains assembly
language instructions.
.section .text
.global main
main:
ldr r1, [r0]
ldr r1, [r0, #3]
The stuff after ".section .text" is TEXT SEGMENT (in the source code).
It just means that code is placed here, it has nothing to do with x86
and segment
ffset addressing with selectors or memory models.You are thinking in terms of Instruction Pointer being in cs:ip on 16
bit realmode x86 programs, am I on the right track? I have bad news
for you: this is not relevant and your argument above is therefore
invalid.
You are arguing about something that I am not. You were arguing about
this with Leigh long before, am I about right? The thing is.. text
segment is just another way to say: "assembly instructions go here"
for the assembly compiler. You keep insisting that some specific
memory model (!) is required. You're just wrong. It's alright, I make
mistakes all the times too and move along.
It's called learning, it's a great thing, not a bad thing.
P
Paul
Text segment is a segment of source code which contains assembly
language instructions.
.section .text
.global main
main:
ldr r1, [r0]
ldr r1, [r0, #3]
The stuff after ".section .text" is TEXT SEGMENT (in the source code).
It just means that code is placed here, it has nothing to do with x86
and segment
ffset addressing with selectors or memory models.You are thinking in terms of Instruction Pointer being in cs:ip on 16
bit realmode x86 programs, am I on the right track? I have bad news
for you: this is not relevant and your argument above is therefore
invalid.
You are arguing about something that I am not. You were arguing about
this with Leigh long before, am I about right? The thing is.. text
segment is just another way to say: "assembly instructions go here"
for the assembly compiler. You keep insisting that some specific
memory model (!) is required. You're just wrong. It's alright, I make
mistakes all the times too and move along.
It's called learning, it's a great thing, not a bad thing.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Shut up you fool. You don't have a clue what you are talking about. I can't
be arsed indenting all that shite and spending time to reply to someone who
is obviously a complete and utter idiot.
H
hanukas
Text segment is a segment of source code which contains assembly
language instructions.
.section .text
.global main
main:
ldr r1, [r0]
ldr r1, [r0, #3]
The stuff after ".section .text" is TEXT SEGMENT (in the source code).
It just means that code is placed here, it has nothing to do with x86
and segment
You are thinking in terms of Instruction Pointer being in cs:ip on 16
bit realmode x86 programs, am I on the right track? I have bad news
for you: this is not relevant and your argument above is therefore
invalid.
You are arguing about something that I am not. You were arguing about
this with Leigh long before, am I about right? The thing is.. text
segment is just another way to say: "assembly instructions go here"
for the assembly compiler. You keep insisting that some specific
memory model (!) is required. You're just wrong. It's alright, I make
mistakes all the times too and move along.
It's called learning, it's a great thing, not a bad thing.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Shut up you fool. You don't have a clue what you are talking about. I can't
be arsed indenting all that shite and spending time to reply to someone who
is obviously a complete and utter idiot.
I agree, only idiot would continue having argue with an idiot. I think
we're done here. ;-)
P
Paul
Text segment is a segment of source code which contains assembly
language instructions.
.section .text
.global main
main:
ldr r1, [r0]
ldr r1, [r0, #3]
The stuff after ".section .text" is TEXT SEGMENT (in the source code).
It just means that code is placed here, it has nothing to do with x86
and segment
You are thinking in terms of Instruction Pointer being in cs:ip on 16
bit realmode x86 programs, am I on the right track? I have bad news
for you: this is not relevant and your argument above is therefore
invalid.
You are arguing about something that I am not. You were arguing about
this with Leigh long before, am I about right? The thing is.. text
segment is just another way to say: "assembly instructions go here"
for the assembly compiler. You keep insisting that some specific
memory model (!) is required. You're just wrong. It's alright, I make
mistakes all the times too and move along.
It's called learning, it's a great thing, not a bad thing.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Shut up you fool. You don't have a clue what you are talking about. I
can't
be arsed indenting all that shite and spending time to reply to someone
who
is obviously a complete and utter idiot.
I agree, only idiot would continue having argue with an idiot. I think
we're done here. ;-)
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I'll decide when I'm done you decide when you're done, there is no "we".in
my text segments
The only 'we' seems to be Leigh and you, pair of idiots.
J
James Kanze
Which assembler? Most of the assemblers I've used didn't have
such directives.
I've never seen an assembler that worked that way, and I can't
imagine what one would achieve doing it. With the assemblers
I've seen that did support .data and .text, these directives
issued entries in the object file which told the linker to put
them in read-write or in read-only memory.
In practice today, any decent linker will support a large number
of segments, both in read-write and in read-only memory. After
all, you don't want the tables for exception stack walkback to
be in the same page as your code, just because they're both
read-only and were compiled in the same translation unit.
J
James Kanze
There are segments, and there are segments. Any modern linker
will understand segments, in order to give you more control of
where things are placed in memory. This has nothing to do with
how the hardware addresses things---both under Windows and under
Linux, the linker will merge several (usually all) logical
segments into a single hardware "segment".
P
Paul
I disagree with some of this but agree with other parts.James Kanze said:
<Wintel specific>
A flat memory model , is mapped with a virtual segmented memory model.
The CS, DS,SS registers will be initialised to the appropriated segments.
each segment will have access privileges.
The hardware can then use segment-offset addressing.
</Wintel specific>
Yes all segments exist in the same flat memory but they have different
access priviledge in a virtual address space..
In a plain flat model there is no segments and no access priviledges.
Its all interrelated with program format , hardware, OS etc etc.
H
hanukas
Most of the assemblers I have used do have such directives:
GNU Assembler, .section .text
NASM, SECTION .text
MASM, .CODE
TASM, CODESEG
So?
Worked what way? You generally want to put data into the data segment
and code into the text aka. code segment. These directives allow the
programmer to do this, what's the problem?
That sounds about right, that's one thing the linker could do.
That they do among other things, agreed. What's your point?
F
Fred Zwarts
hanukas said:
This seems to be a simplification to me.
Often there are more than two "partitions"
(to avoid the word segment, which seems to call for other associations).
Partitions can have attributes, like read-only vs. read/write, executable, shareable, etc.
For example:
Compile time constants can be put in read-only non-executable shared partitions,
which are often refered to as "text".
Code can be stored in read-only executable shared partitions.
Variables can be stored in read/write non-executable non-shared partitions.
System wide global variables can be stored in read/write non-executable shared partitions.
The linker/loader lays out the memory by gathering partitions which compatible attributes.
Not all hardware support all attributes.
But it is not true that in general code is identical to text,
in particular for platforms where there is a difference between executable and non-executable partitions of memory.
H
hanukas
Worked what way? You generally want to put data into the data segment
It is indeed, I used the term "generally" to make it more obvious.
The concept of "text segment" does not require x86 centric Real mode
segment:Offset addressing; because. Here we can write a thousand word
essay about addressing modes, protection, read-write-execute-present
(and other) flags, and so on and on.
Of course, who doesn't know that? That's what linkers do.
It is indeed, I used the term "generally" to make it more obvious.
The concept of "text segment" does not require x86 centric Real mode
segment:Offset addressing; because. Here we can write a thousand word
essay about addressing modes, protection, read-write-execute-present
(and other) flags, and so on and on.
Of course, who doesn't know that? That's what linkers do.
J
Jorgen Grahn
Please don't invent a new name -- it's known as a "segment" in all
linking environments I've seen, from the Amiga to Texas Instruments to
Unix ...
This is just another word with overloaded meanings.
/Jorgen
J
James Kanze
The directive here is .section. The .text is simply a symbol; you
can,
at least in principle, use anything you want (and a really good
compiler
will use more than just .text and .data).
Ditto. The directive is SECTION; the .text is just a user defined
symbol.
The directives allow the programmer to divide the program up into one
or
more segments. Other directives tell the linker where to put these
segments. There may be defaults for some symbols, but they're
certainly
not universal, and they don't mean that you cannot use other segments,
or other names.
J
James Kanze
There's nothing Wintel specific about the segments defined by the
Sparc
assembler, and managed by the Sparc linker. The segments, in this
case,
disappear once the executable is loaded.
I've yet to see an assembler/linker that didn't support some form of
segments, and most of my experience is on machines with a flat memory
model.
Obviously, you didn't read what you are responding to, or you didn't
understand it. The word segment has two different technical meanings.
One refers to the hardware implementation used by Intel. The other,
older, refers to the logical organization of the generated code into
different segments, which the linker manages separately. I dealt with
segments long before the 8086 appeared, on machines with flat
addressing
and no memory protection.
J
James Kanze
It was known as a segment in ASM80 (for the Intel 8080). I rather
imagine that that's where Intel got the name for the concept in the
8086. Although even in ASM86, the word segment meant something
completely different from what it meant when applied to the hardware.
H
hanukas
I can write assembler compiler that can compile this:
"jesus .text", that doesn't prove anything. A text segment is
generally where the assembler puts code. A fact. Come on, what are you
smoking?
E
Ebenezer
Perhaps "Paul" is a pseudonym for someone regulars would
recognize if the truth were told? If that's the case,
another possibility is someone being intentionally
disputatious or acting confused. At any rate, I hope
"Paul" and others will cut out the cursing here.
Brian Wood
Ebenezer Enterprises
http://webEbenezer.net
P
Paul
Yes I read what you wrote re:James Kanze said:
"Any modern linker will understand segments, in order to give you more
control of where things are placed in memory. This has nothing to do with
how the hardware addresses things"
And I disagree with you , it is related to how the hardware addresses in
most modern PC's. When a program is loaded the registers are set up to
mirror the program segments, on a windows implementation I know, I am not
saying this is the case on every implementation.
A segment is *not* a hardware addressing mode, or 'hardware implementation'
as you put it.
A segment is a portion , a piece , a section, find a dinosaurus.
A memory segment is therefore a piece of memory, and this is what we are
talknig about/ The memory segments we are talking about are text, code ,
data etc.
There is no need to confuse this with CPU addressing modes. Having said that
the CPU addressing mode is related to memory segments, in many cases, even
on some flat models as I explained with the wintel example. Windows uses
segment registers in application programs of 16,32 and 64-bit addressing
modes. The registers are initialised by the program loader to point to their
respective segments as defined in the program header.
You can suggest you were talking about a segment of pizza from last night ,
but the discussion here wasn't about that.
The hardware won't work without the OS and vice-versa, the two are
interelated.
Yes here is one I use today:
..NOLIST
#INCLUDE "ti83plus.inc"
#DEFINE ProgStart $9D95
..LIST
..ORG ProgStart - 2
..DB t2ByteTok, tAsmCmp
b_call(_ClrLCDFull)
LD HL, 0
LD (PenCol), HL
LD HL, msg
b_call(_PutS)
b_call(_NewLine)
RET
msg:
.DB "Output text", 0
..END
..END
There are no segments its a flat memory model, but perhaps you are confusing
this with the wintel .flat model.
But there are no TEXT or CODE segments, in the way we know them today. And
as a bonus there is also a function in there .
So that makes Leighs mega repetative statement incorrect, that...a function
only exists as machine code in a text segement .