[Coco] questions about constants
Wayne Campbell
asa.rand at yahoo.com
Tue Sep 15 16:48:39 EDT 2009
>Incidentally, that would be fcs rather than fcc - fcs causes bit 7 in
the final character to be set, fcc does not.
The reason I used fcc is because I did not notice that the token names have bit 7 set. oops.
________________________________
From: William Astle <lost at l-w.ca>
To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
Sent: Tuesday, September 15, 2009 12:59:26 PM
Subject: Re: [Coco] questions about constants
Wayne Campbell wrote:
> Everything you said here is exactly what I thought was going on. I'm guessing that the token list is reserving memory for each label as a temporary list that's used to identify the keywords in the fcb's in the module, something like:
>
> L0140 fcb $01
> fcb $01
> fcb $50 P
> fcb $41 A
> fcb $52 R
> fcb $41 A
> fcb $CD M
>
> might have been originally coded:
>
> T.SIZE equ $01 since almost all of the tokens have a size of 1, this might have been used
>
> keywords fcb T.PRAM
> fcb T.SIZE
> fcc "PARAM"
>
> I'm still not certain, but this at least makes more sense to me than trying to match up 256 program variables to 256 token codes.
That seems quite likely, actually. That would also explain why there
would be no "references" since the disassembler doesn't know what all
the random data in fcb/fcc statements is so it cannot reconstruct the
original rmbs.
Incidentally, that would be fcs rather than fcc - fcs causes bit 7 in
the final character to be set, fcc does not.
This is the wonderful thing about asm programming. There is no such
thing as a "variable" as far as asm is concerned - only addresses and
values at addresses.
>
> Wayne
>
>
>
>
> ________________________________
> From: Lothan <lothan at newsguy.com>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Monday, September 14, 2009 9:42:56 PM
> Subject: Re: [Coco] questions about constants
>
> The ORG statement effectively sets the module offset to the address specified, although it can be a bit more complicated that than when defining structures. In effect, the code you give
>
> ORG 0
> A.LABEL1 rmb 1
> A.LABEL2 rmb 1
> A.LABEL3 rmb 2
> A.LABEL4 rmb 1
> A.LABEL equ .
>
> set the base to zero, then reserves one byte of memory for A.LABEL2, one byte for A.LABEL2, and so forth. Looking at the actual binary data, it would something like this:
>
> 00 00 00 00 00 ... remainder of binary data
>
> An equate (or EQU) assigns a constant value to a label, but the label is actually replaced with the real value. In other words, take this code:
>
> Zero EQU 0
>
> MySub LDA Zero
> LDB 0
> RTS
>
> Run that through the assembler, then disassamble the resulting binary and you'll see this:
>
> MySub LDA 0
> LDB 0
> RTS
>
> Going back to the top, A.LABEL EQU . is (if my brain is working half right) 5 since the current module offset is 5.
>
>
> --------------------------------------------------
> From: "Wayne Campbell" <asa.rand at yahoo.com>
> Sent: Sunday, September 13, 2009 4:14 PM
> To: <coco at maltedmedia.com>
> Subject: Re: [Coco] questions about constants
>
>> I believe I understand the compiler directives and pseudo op codes better now. In order to make sure I am looking at things correctly, the following is true?
>>
>> org 0 sets the current . value to 0
>>
>> A.LABEL1 rmb 1 this A memory address is relative 0 to org
>> A.LABEL2 rmb 1 this A memory address is relative 1 to org
>>
>> A.LABEL3 rmb 2 this A memory address is relative 2 or org
>> A.LABEL4 rmb 1 this A memory address is relative 4 to org
>>
>> I know that equ is a system equate. What I'm not sure of, is what it is equating.
>>
>> For example, say the above is true, and the following line comes next in the list:
>>
>> A.LABEL5 equ
>>
>> does this mean that A.LABEL5 is being set to a value of 5, or the address of 5 relative to org?
>>
>> Wayne
>>
>>
>>
>> ________________________________
>> From: "jdaggett at gate.net" <jdaggett at gate.net>
>> To: Wayne Campbell <asa.rand at yahoo.com>; CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
>> Sent: Saturday, September 12, 2009 8:16:24 PM
>> Subject: Re: [Coco] questions about constants
>>
>>
>>
>> Wayne
>>
>> FCB, FCC, FCS are assembler directives and not opcodes. What they do is tell the
>> assembler at that place in memory to reserve a single byte, a double byte or multiple
>> bytes. This used to hold a spot for data, screen prompts or table entries.
>>
>> Memory for all processors are in binary form. Integers are represented as a binary
>> number. They can be 8 bit, 16 bit or even 32 bit form. The more bits used for integer the
>> larger teh integer value you can have. 8 bit integers are limited 0 tp 255 if unsigned and -
>> 127 to 128 if signed.
>>
>> Real numbers are stored as floating point binary numbers per the IEEE standard. Well
>> the Coco is not IEEE standard as the DEC Basic was written before the IEEE standard
>> was formed. To store a IEEE binary floating point number you need to 4 bytes for single
>> precision, 8 bytes for double presicion. In single presicion you have a 23 bit mantissa,
>> one sign bit and an 8 bit weighted exponent. For double presicion you have an 11 bit
>> weighted exponent, one sign bit and 62 bit mantissa.
>>
>> These require any program to reserve appropriate amount of memory for each number
>> used. You can use FCBs to reserve the bytes needed. In the case you only want to
>> declare the space and not assign a value, you can use the asembler directive RMB to
>> reserve space. If you wish to reserve 4 bytes you can do this.
>>
>> FPACCA RMB 4
>>
>> This will reseve 4 bytes for floating point accumaltor A.
>>
>> Assembler directives are a way to tell the assembler that all the code is not machine
>> code. Some maybe data, a macro so that you do not have to type the same code over
>> and over again.
>>
>> hope this helps
>>
>> james
>>
>> On 12 Sep 2009 at 16:41, Wayne Campbell wrote:
>>
>>> I have looked at a dozen tutorials on assembly language programming. None of them address the op codes fcb, fcc or fcs, so I'm asking the assembly gurus on this list to help explain this to me.
>>>
>>> What are the differences between fcb, fcc and fcs?
>>> Is there a fci or fcr(/f/d) (for integer and real(/float/double) values)?
>>>
>>> I know that:
>>>
>>> fcb = form constant byte = any constant numeric byte value?
>>> fcc = form constant char = any constant character that is displayable?
>>> fcs = form constant string = any constant string?
>>>
>>> Are the following equivalent, so far as the assembler is concerned?
>>>
>>> A. form constant byte:
>>>
>>> fcb $20
>>> fcb $20
>>> fcb $20
>>> fcb $20
>>> fcb $20
>>> fcb $20
>>> fcb $20
>>> fcb $20
>>> fcb $20
>>> fcb $20
>>> fcb $20
>>> fcb $20
>>> fcb $42 B
>>> fcb $41 A
>>> fcb $53 S
>>> fcb $49 I
>>> fcb $43 C
>>> fcb $30 0
>>> fcb $39 9
>>> fcb $0A
>>>
>>> B. form constant string:
>>>
>>> fcs / BASIC09/
>>> fcb $0A
>>>
>>> C. would using form constant char be equivalent?
>>>
>>> fcc ' '
>>> fcc ' '
>>> fcc ' '
>>> fcc ' '
>>> fcc ' '
>>> fcc ' '
>>> fcc ' '
>>> fcc ' '
>>> fcc ' '
>>> fcc ' '
>>> fcc ' '
>>> fcc ' '
>>> fcc 'B'
>>> fcc 'A'
>>> fcc 'S'
>>> fcc 'I'
>>> fcc 'C'
>>> fcc '0'
>>> fcc '9'
>>> fcb $0A
>>>
>>> Wayne
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Coco mailing list
>>> Coco at maltedmedia.com
>>> http://five.pairlist.net/mailman/listinfo/coco
>>
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
>
>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>
--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco
More information about the Coco
mailing list