1 Nov 2008 15:13
6 Nov 2008 17:58
heyy11/06/2008 08:58:31
mike v <name <at> supportsquadron.net>
2008-11-06 16:58:31 GMT
2008-11-06 16:58:31 GMT
Michael Vincent here, and I wanted to let you know about an exciting thing I have for you. Its called the Underground Cash system, let me give you the run down of this. I was once what you would consider middle class, maybe even lower middle class. I was literally basically broke and realized I had to change my life. I hated being broke so much. Working a job that paid not much more then minimum wage was anything but thrilling to me. I then met a guy named Jason who turned my life around... I was itching to figure out how he was making his money. You can visit the link below to find out what happened. Visit Here: http://supportsquadron.net/54cz1034908m4 Sincerely Yours, Michael Vincent 11/06/2008 08:58:31 refrain from; http://supportsquadron.net/55cz1034908b4 3867 W. Market Street, Suite 256 Akron, OH 44333to edit communication preferences http://supportsquadron.net/unsub.php?l=4&e=cgen <at> sources.redhat.com or post PO-Box-350,-Eastport,-NY-11941
7 Nov 2008 16:18
Here is a job for you 18 11/07/08 10:18:06}
Amy <amy <at> nomoretoughtimes.com>
2008-11-07 15:18:06 GMT
2008-11-07 15:18:06 GMT
Michael Vincent here, and yes I wanted to let you in on a very special Secret of Mine.http: http://nomoretoughtimes.com/8cz1034745m6 First of all, I used to work a very bad paying job and I could hardly pay my bills. I was feeling really sad and down. It was at this point where I was looking for any way possible to Get Cash . Luckily, a guy named Jason came to my call. Jason was already Loaded with a huge mansion and tennis court. I asked him if what he did to Get cash was Legal Jason excitingly answered yes, and if I can Do it then you can too. Jason didn't feel bad for me, he doesn't like handouts. Jason taught me how to make life more relaxing by working smarter instead of harder. I asked Jason to help me create a website that would help others, heres what he Put together: Below I would like you to check it out. http://nomoretoughtimes.com/8cz1034745m6 Thanks For your time, Michael Vincent.(Continue reading)
8 Nov 2008 17:38
Labels resolving to zero
Brian Mokrzycki <brian-mokrzycki <at> uiowa.edu>
2008-11-08 16:38:46 GMT
2008-11-08 16:38:46 GMT
I'm currently trying to port binutils to a custom digital signal
processing architecture. I've run into a couple issues but I can't
seem to figure this one out. I am trying to implement a branching
instruction such as in the example below.
_START:
LD R4, 8
NOP
LOOP: ADD R1,R2,R3
SUB R4,R4,1
BNEZ LOOP
The LOOP label argument for BNEZ is a 24-bit absolute address (well
actually 26-bit but I wanted to make sure byte boundaries weren't
causing more hidden problems). When I assemble this, the LOOP label
always resolves to 0 <_start>. Furthermore when I go and actually
link the object file, the disassembly of BNEZ becomes this very very
long sequence of bytes and is an *unknown* instruction.
Here's what I think are the relevant lines in my .cpu file to describe
the branch instruction. Please note that I haven't implemented the
flags yet so the PC is updated unconditionally for now.
; Field Definition
(df f-abs24 "Absolute 24-bit Jump Address" ((ISA wvfe-cop) ABS-
ADDR) 44 24 INT
((value pc) (sra WI pc (const 2)))
((value pc) (sll WI value (const 2))))
(Continue reading)
11 Nov 2008 01:06
Re: Labels resolving to zero
Brian Mokrzycki <brian-mokrzycki <at> uiowa.edu>
2008-11-11 00:06:25 GMT
2008-11-11 00:06:25 GMT
I already solved my problem. I'm sure the developers already know this but for anyone else trying to do a port it wasn't exactly clear. Turns out that the address fields are filled in with zeros if they can't be resolved during the assembly of relocatable object files. These unresolved addresses are then calculated and filled in during the linking phase. I had my BFD definitions wrong for the absolute and relative relocatable addresses and it would spit out a bit pattern that didn't line up with the field in question. This caused the disassembler to see an *unknown* instruction and messed up the alignment of the other instructions. So I fixed all that and it appears to be working. -Brian On Nov 8, 2008, at 10:38 AM, Brian Mokrzycki wrote: > I'm currently trying to port binutils to a custom digital signal > processing architecture. I've run into a couple issues but I can't > seem to figure this one out. I am trying to implement a branching > instruction such as in the example below. > > _START: > LD R4, 8 > NOP > LOOP: ADD R1,R2,R3 > SUB R4,R4,1 > BNEZ LOOP > > The LOOP label argument for BNEZ is a 24-bit absolute address (well > actually 26-bit but I wanted to make sure byte boundaries weren't(Continue reading)
11 Nov 2008 06:18
opcodes port instructions in cgen.info yield "unbound variable: opc-file-path "
Alan Lehotsky <qsmgmt <at> earthlink.net>
2008-11-11 05:18:09 GMT
2008-11-11 05:18:09 GMT
I've done two cgen machines (but it's been years since the last time I
worked with this.
I've really tried hard to exactly follow the steps in Section 5.5 of
the cgen.info file.
I tried Fche's suggestion of doing a (set! .... ), and had no
success. There are at least 3-4
people who've encountered this problem (as far back as 2002) and I
don't see any indication in
the mailing-list archives that a solution has been posted...
- I've got a TARGET.cpu and TARGET.opc file.
- I've done
cd src/cgen
guile
guile> (load "dev.scm")
guile> (load-opc)
guile> (cload #:arch "TARGET")
...... ;; no errors or warnings here
guile> (cgen-asm.in)
(cgen-asm.in)
Generating atdsp-asm.in ...
Backtrace:
In ./opc-asmdis.scm:
89: 0* (opc-file-path)
89: 1 [gen-extra-asm.c ...
(Continue reading)
11 Nov 2008 21:53
Re: 64-bit instruction word w/ multiple opcodes
Brian Mokrzycki <brian-mokrzycki <at> uiowa.edu>
2008-11-11 20:53:01 GMT
2008-11-11 20:53:01 GMT
I've finally gotten back to this and have made some good progress
using your suggestions. Currently I have two ISA defined one with 64-
bits for the integer operations and a 32-bit one for floating point
operations. During assembly I divide the incoming string using the
"II" token and process each instruction separately. Then before they
are set to be finished up and sent to bfd for output I bitwise OR the
32-bit to the lower 32-bits of the 64-bit instruction. This seems to
work.
The biggest problem I've had is with disassembly. Looking at the MEP
port it seems that it's able to select between ISAs before it calls
the print_insn function. I tried the same trick with no luck. Here's
what my code looks like...
static int
wvfe_print_insn (CGEN_CPU_DESC cd,
bfd_vma pc,
disassemble_info *info)
{
int status;
int i;
static CGEN_BITSET * isa_select = NULL;
int buflen = 8;
const bfd_byte mask[8] = {0x00, 0x00, 0xe0, 0xFF, 0xFF, 0xFF, 0xFF,
0xFF};
bfd_byte buf[8];
bfd_byte cop_buf[8];
bfd_byte fop_buf[8];
if(isa_select == NULL)
(Continue reading)
15 Nov 2008 15:45
Re: opcodes port instructions in cgen.info yield "unbound variable: opc-file-path "
Alan Lehotsky <qsmgmt <at> earthlink.net>
2008-11-15 14:45:32 GMT
2008-11-15 14:45:32 GMT
I see what my problem was. I was expecting too much from running
interactively.
The suggestion regarding running various generators (like the `(cgen-
asm.in)' is going to always fail complaining
about the unbound variable. You would need to invoke guile and cgen
with all the appropriate flags that are hidden in
the make files. The porting suggestion is directed to the idea that
you run interactively, looking at the generated .c and .h files
as they flash by on the screen. Once you're happy, then you go off
and do the
make stamp-TARGET
or whatever in the subdirs. I will see if I can write up a patch to
the docs regarding this.
On Nov 11, 2008, at 00:18, Alan Lehotsky wrote:
>
> - I've got a TARGET.cpu and TARGET.opc file.
> - I've done
>
> cd src/cgen
> guile
> guile> (load "dev.scm")
> guile> (load-opc)
> guile> (cload #:arch "TARGET")
> ...... ;; no errors or warnings here
> guile> (cgen-asm.in)
(Continue reading)
15 Nov 2008 15:55
selecting between two forms of an instruction
Alan Lehotsky <apl <at> alum.mit.edu>
2008-11-15 14:55:58 GMT
2008-11-15 14:55:58 GMT
Working on a port for a machine with 16 bit and 32 bit fixed length instructions. The machine is somewhat like an ARM/Thumb architecture, but there is no mode switch. You use the 16 bit instructions if you have short displacements or only need to access a subset of all the registers. It occurs to me that I could ALWAYS generate 32 bit instructions in the assembler and let the linker relax 32 bitters to 16 bitters based on the actual requirements of the program. Is there any downside to this strategy? I've done this in the past for branching instructions and (on the IP2K) the insertion and deletion of bank switching instructions - but never so aggressively where nearly every instruction has a short form. -- Al
1 Dec 2008 15:14
RSS Feed