Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Tue, 17 Mar 2009 08:27:48 -0700 (PDT), Antti Lukats wrote: >well assembler is GOOD if it exist :) >so any soft-core with assembler is ok >but there is no assembler for nibz? so == useless. >no C, no assembler, == not possible to use :( I think you're being a bit blinkered about this. Writing an assembler for a machine as simple as nibz is not much more than a day's work if you are sensible about your choice of tool (Tcl, Perl?) and limit your ambitions reasonably. No rocket science required. >a non working somesort of forht partially adopted >but not really tested does not count as development tool. >a simple assembler would. Yes. gcc is not the only act in town for these very simple, small machines. A simple assembler gets you going, and a nice macro-generating assembler gets you productive, for very little investment in the tool chain. Of course a full C toolchain is way better; but targeting gcc to a new machine is not for the faint-hearted, I think (it's not for me at all, I would have no idea how to start). I'd consider throwing together an assembler for nibz myself, but like many others here I simply can't divine its specification from the published docs - and that's my real problem with it. If jacko wants it to become more widely accepted he must put in the effort to document it intelligibly (or find someone else who can do so). He's competing in a very crowded marketplace, and has erected very effective barriers to other people's understanding of his offering; not a smart move. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 138976
On Mar 17, 6:12=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Tue, 17 Mar 2009 08:27:48 -0700 (PDT), > > Antti Lukats wrote: > >well assembler is GOOD if it exist :) > >so any soft-core with assembler is ok > >but there is no assembler for nibz? so =3D=3D useless. > >no C, no assembler, =3D=3D not possible to use :( > > I think you're being a bit blinkered about this. > Writing an assembler for a machine as simple as > nibz is not much more than a day's work if you > are sensible about your choice of tool (Tcl, Perl?) > and limit your ambitions reasonably. =A0No rocket > science required. > > >a non working somesort of forht partially adopted > >but not really tested does not count as development tool. > >a simple assembler would. > > Yes. gcc is not the only act in town for these > very simple, small machines. =A0A simple assembler > gets you going, and a nice macro-generating > assembler gets you productive, for very little > investment in the tool chain. =A0Of course a full > C toolchain is way better; but targeting gcc to a > new machine is not for the faint-hearted, I think > (it's not for me at all, I would have no idea > how to start). > > I'd consider throwing together an assembler for > nibz myself, but like many others here I simply > can't divine its specification from the published > docs - and that's my real problem with it. =A0If > jacko wants it to become more widely accepted he > must put in the effort to document it intelligibly > (or find someone else who can do so). =A0He's > competing in a very crowded marketplace, and > has erected very effective barriers to other > people's understanding of his offering; > not a smart move. > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated. right Jonathan a simple assembler would suffice a good macro assembler is better or then can use c preprocessor on the asm source or use some retargetable assembler.. but if the core specs itselfs are really fuzzy then its hard to use it, or make an assembler for it Antti From bernd.paysan@gmx.de Tue Mar 17 10:35:52 2009 Path: flpi141.ffdc.sbc.com!flph199.ffdc.sbc.com!prodigy.com!flph200.ffdc.sbc.com!prodigy.net!newshub.sdsu.edu!feeder.erje.net!bnewspeer00.bru.ops.eu.uu.net!bnewspeer01.bru.ops.eu.uu.net!emea.uu.net!read.news.uk.uu.net!not-for-mail Message-Id: <ok3596-n4f.ln1@annette.zetex.de> From: Bernd Paysan <bernd.paysan@gmx.de> Subject: Re: Zero operand CPUs Newsgroups: comp.lang.forth,comp.arch.embedded,comp.arch.fpga Followup-To: comp.lang.forth Date: Tue, 17 Mar 2009 18:35:52 +0100 References: <95f3256f-1304-48ba-a982-15562c1cc585@h20g2000yqn.googlegroups.com> <ebd30a00-1790-4e0e-8de5-a4f6c8e6c66f@e38g2000yqa.googlegroups.com> <49bfc0c7$0$14779$8404b019@news.wineasy.se> User-Agent: KNode/0.10.9 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit Lines: 13 NNTP-Posting-Host: 62.190.115.228 X-Trace: 1237311602 read.news.uk.uu.net 19014 62.190.115.228:10618 X-Complaints-To: abuse@uk.uu.net Xref: prodigy.net comp.lang.forth:140908 comp.arch.embedded:302772 comp.arch.fpga:152305 X-Received-Date: Tue, 17 Mar 2009 13:40:18 EDT (flpi141.ffdc.sbc.com) David Brown wrote: > So a compiler without a debugger is somewhat limited but still useful, > but a debugger without a compiler is rather less useful! I've done a debugger on my last b16 version, and it doesn't come with a compiler, either (only an assembler), and I assure you, the debugger *is* useful. At least that's what the coworker who does the firmware development tells me. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/Article: 138977
On Mar 17, 9:12 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > On Tue, 17 Mar 2009 08:27:48 -0700 (PDT), > > Antti Lukats wrote: > >well assembler is GOOD if it exist :) > >so any soft-core with assembler is ok > >but there is no assembler for nibz? so == useless. > >no C, no assembler, == not possible to use :( > > I think you're being a bit blinkered about this. > Writing an assembler for a machine as simple as > nibz is not much more than a day's work if you > are sensible about your choice of tool (Tcl, Perl?) > and limit your ambitions reasonably. No rocket > science required. That's about right. > >a non working somesort of forht partially adopted > >but not really tested does not count as development tool. > >a simple assembler would. > > Yes. gcc is not the only act in town for these > very simple, small machines. Forth covers a wide range of hardware and software these days. The op mentioned Moore's ideas on the subject. Mr. Moore's current ideas are about full custom vlsi Forth chips designed with Forth CAD software. They have 700Mhz core that use 1/30 the power of an MSP430 for a given computation and are small enough to fit a hundred or more on a tiny chip and program them with the simplest Forth compilers yet using libraries of code objects written by various teams of people. Other people have fit multiple tiny 200 mip code compatible core on small FPGA. These are some of the things the op refered to as Chuck Moore's ideas on this subject. The op also talked about a project to implement a simple processor with modest performance requirements and write code himself. He is not alone in being interested in that sort of thing, but rolling your own hardware/software or using gcc are certainly not the only options here. > A simple assembler > gets you going, and a nice macro-generating > assembler gets you productive, for very little > investment in the tool chain. Of course a full > C toolchain is way better; but targeting gcc to a > new machine is not for the faint-hearted, I think > (it's not for me at all, I would have no idea > how to start). The first page of gcc documentation will explain why you would need to choose a different path if you want to try to implement a C for these designs. > I'd consider throwing together an assembler for > nibz myself, but like many others here I simply > can't divine its specification from the published > docs - and that's my real problem with it. If > jacko wants it to become more widely accepted he > must put in the effort to document it intelligibly > (or find someone else who can do so). He's > competing in a very crowded marketplace, and > has erected very effective barriers to other > people's understanding of his offering; > not a smart move. People are making knock-offs of 20+ year old Forth chips in modern FPGA and are now getting 50 mips or more. People are making newer smaller Forth chips with tens or hundreds of thousands of Forth mips and at very lower power and cost. Some people are making their own designs tuned for the performance that they need which might be just be a small control processor with source code that doesn't need to be very fast or might be specialized for some purpose. Choosing a model that offers a few mips and writing your own assembler for it are not your only options. However it is how the inventor of Forth got started in hardware design in the early 80s after thirty years experience writing code. The first step was 4-10 mips, then 100, 220, 700, 18,000, 30,000, 100k+ and beyond. It started with one person's work and expanded to include a hundred other people doing cad work in Forth or writing tools and library code for target chips etc. so you don't have to redo it all yourself. Best WishesArticle: 138978
>>well assembler is GOOD if it exist :) >>so any soft-core with assembler is ok >>but there is no assembler for nibz? so == useless. >>no C, no assembler, == not possible to use :( > >I think you're being a bit blinkered about this. >Writing an assembler for a machine as simple as >nibz is not much more than a day's work if you >are sensible about your choice of tool (Tcl, Perl?) >and limit your ambitions reasonably. No rocket >science required. You can also use cpp in front of your assembler. -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138979
On Mar 17, 9:04=A0pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal Murray) wrote: > >>well assembler is GOOD if it exist :) > >>so any soft-core with assembler is ok > >>but there is no assembler for nibz? so =3D=3D useless. > >>no C, no assembler, =3D=3D not possible to use :( > > >I think you're being a bit blinkered about this. > >Writing an assembler for a machine as simple as > >nibz is not much more than a day's work if you > >are sensible about your choice of tool (Tcl, Perl?) > >and limit your ambitions reasonably. =A0No rocket > >science required. > > You can also use cpp in front of your assembler. > > -- > These are my opinions, not necessarily my employer's. =A0I hate spam. sure can use GCC as i already mentioned 4 posts ago :) but it not always as good as good macro assembler AnttiArticle: 138980
>BTW, ZPU may have a GCC compiler, but without a debugger, is that >really useful? There aren't many projects done in C that are debugged >without an emulator. I'm happy without a debugger, at least as long as the edit/compile/run cycle is fast. Besides, a lot of the quirks I'm chasing are timing issues where you need a scope to see what's going on. What do you use for a debugger when working on perl/python code? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138981
>Getting the compiler to limit the stack size is >clearly possible (Transputer, anyone? it had a >3-register stack). But this is certain to >cause more memory references to escape to >memory. It's a compromise, like everything else. 3 is a small number. If you have 8 or 16, the same ballpark as the number of registers in a typical CPU, then most code never spills to memory. It was a long time ago, so my memory is fuzzy. I think the Mesa/Cedar system had a rule of nothing on the stack at procedure calls except the arguments/results. I think the only time that sane code spilled was calls to get the arguments of a call, things like: x = foo(a, baz(b)); -- These are my opinions, not necessarily my employer's. I hate spam.Article: 138982
Hi, Not sure I want to jump into this (but I couldn't resists ;-) ) but I created a stack RISC processor back in 1990 which was targetting space application. It had the ADA run-time kernel in hardware and support 8 tasks in hardware. We handled the memory accesses using cache, there is no real difference in cache for stack machine or register-file based CPU. We did however had one operand to minimize the program code size. Instead of just operating on the two operand on the stack, one operand was address with a stack offset. This removed tons of push instructions and thus minimized the program code space. A processor needs assembler, simple as that. Debugger is nice to have but you can develop stuff without it, it just takes longer time. C compiler is needed if you want more users. With Xilinx 6-LUT, you can really make small 16-bit RISC machines which is register file based. Programming a register based CPU in assembler is much easier than a stack machine. I crafted a couple of years ago a 16-bit machine which could be as small as 200 LUTs (4-LUT) but was around 300 LUTs in general. It might be possible to do a 16-bit RISC at around 100 LUTs (6-LUT). So the only benefit I see a stack machine has is more compact code. G=F6ran BilskiArticle: 138983
Jonathan Bromley wrote: > On Tue, 17 Mar 2009 08:27:48 -0700 (PDT), > Antti Lukats wrote: > >> well assembler is GOOD if it exist :) >> so any soft-core with assembler is ok >> but there is no assembler for nibz? so == useless. >> no C, no assembler, == not possible to use :( > > I think you're being a bit blinkered about this. > Writing an assembler for a machine as simple as > nibz is not much more than a day's work if you > are sensible about your choice of tool (Tcl, Perl?) > and limit your ambitions reasonably. No rocket > science required. Write it in Forth. Also about a day's work. Use a PC Forth to generate code for it, and when you get it working set up a little "talker" for interactive debugging. You don't need a full Forth in the target for that. We have several times managed low-level controllers (not quite "smart" enough to support a full Forth VM) that way. ... > I'd consider throwing together an assembler for > nibz myself, but like many others here I simply > can't divine its specification from the published > docs - and that's my real problem with it. If > jacko wants it to become more widely accepted he > must put in the effort to document it intelligibly > (or find someone else who can do so). He's > competing in a very crowded marketplace, and > has erected very effective barriers to other > people's understanding of his offering; > not a smart move. Ah, well, that's a problem. If you can't get a detailed description of the instruction set, you're stuck. Cheers, Elizabeth -- ================================================== Elizabeth D. Rather (US & Canada) 800-55-FORTH FORTH Inc. +1 310.999.6784 5959 West Century Blvd. Suite 700 Los Angeles, CA 90045 http://www.forth.com "Forth-based products and Services for real-time applications since 1973." ==================================================Article: 138984
On 17 Mar, 17:33, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > On Mar 17, 6:12=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> > wrote: > > > > > > > On Tue, 17 Mar 2009 08:27:48 -0700 (PDT), > > > Antti Lukats wrote: > > >well assembler is GOOD if it exist :) > > >so any soft-core with assembler is ok > > >but there is no assembler for nibz? so =3D=3D useless. > > >no C, no assembler, =3D=3D not possible to use :( > > > I think you're being a bit blinkered about this. > > Writing an assembler for a machine as simple as > > nibz is not much more than a day's work if you > > are sensible about your choice of tool (Tcl, Perl?) > > and limit your ambitions reasonably. =A0No rocket > > science required. > > > >a non working somesort of forht partially adopted > > >but not really tested does not count as development tool. > > >a simple assembler would. > > > Yes. gcc is not the only act in town for these > > very simple, small machines. =A0A simple assembler > > gets you going, and a nice macro-generating > > assembler gets you productive, for very little > > investment in the tool chain. =A0Of course a full > > C toolchain is way better; but targeting gcc to a > > new machine is not for the faint-hearted, I think > > (it's not for me at all, I would have no idea > > how to start). > > > I'd consider throwing together an assembler for > > nibz myself, but like many others here I simply > > can't divine its specification from the published > > docs - and that's my real problem with it. =A0If > > jacko wants it to become more widely accepted he > > must put in the effort to document it intelligibly > > (or find someone else who can do so). =A0He's > > competing in a very crowded marketplace, and > > has erected very effective barriers to other > > people's understanding of his offering; > > not a smart move. > > -- > > Jonathan Bromley, Consultant > > > DOULOS - Developing Design Know-how > > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > > Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK > > jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com > > > The contents of this message may contain personal views which > > are not the views of Doulos Ltd., unless specifically stated. > > right Jonathan > > a simple assembler would suffice > a good macro assembler is better > or then can use c preprocessor on the asm source > or use some retargetable assembler.. > > but if the core specs itselfs are really fuzzy then its > hard to use it, or make an assembler for it There is now a link on the instruction set page presenting an english text description of the BO instruction. All other instructions follow a similar symbology. SU always has carry, BO always rotates through carry. DI leaves the carry alone, just like all the register/memory move instructions. All opcodes above 15 are subroutine call addresses. There are no general purpose register fields in the 4 bits of hardwired 16 opcodes (0-15), although there is some pattern to it. Yes the indexing has been fixed, i.e. non-clocked assignment to indirect, which is also good for speed, as well as executing the current instruction rather than the current operation with the last instruction's indirection register. (this removes a row of clocked flip-flops). Personally I find what else I have to explain as a difficult task. I would accept any correct documentation which falls under the BSD licence, or has no publication restriction. The simplicity of the assembler was the main reason for the instruction choice, and lack of multiple addressing modes. In some senses the assembler complexity indicates how much decode processing is required for an instruction. There is a GPL assembler written in forth, using the gforth sytem this is suitable for macro programming. It's a tiny amount of code. The lack of certain complicated instructions takes some working around, but it is not beyond a talented code writer. The macro feature is not really relevant, as a subroutine will work, but I suppose some critical inline macros would be useful to some to prevent excessive return stack juggling. All instructions are fixed and final, except RE and SE, which are useful only in multi-tasking, and even then there is some debate. cheers jackoArticle: 138985
Hey guys, I am working on an image processing FPGA design and plan to use an embedded uB to control certain FPGA functions and perform some preliminary analysis on processed image data written into a FIFO peripheral. With any luck, the uB will be powerful enough to do everything (analysis/calculation), but I have no experience with uB and cannot really count on that. With further development of the recognition etc. I was considering using a PowerPC CPU. If I did this, what would you recommend as the best way to communicate between the uB and the PowerPC? I am just learning embedded systems and any resources would be great. Thanks, GintsArticle: 138986
On 17 Mar, 20:17, Goran_Bilski <goran.bil...@xilinx.com> wrote: > Hi, > > Not sure I want to jump into this (but I couldn't resists ;-) ) but I > created a stack RISC processor back in 1990 which was targetting space > application. > It had the ADA run-time kernel in hardware and support 8 tasks in > hardware. > We handled the memory accesses using cache, there is no real > difference in cache for stack machine or register-file based CPU. > We did however had one operand to minimize the program code size. > Instead of just operating on the two operand on the stack, one operand > was address with a stack offset. > This removed tons of push instructions and thus minimized the program > code space. Sounds ok. I did think of using such a pick optimization, but considered it responsable for a potential cache slowdown as the design progresses. In nibz picking lower in the stack like this may be possible, but is not advised for scalability reasons. I have the idea too that any object C (++) should have method local instance variables only, indicating which method has write access to the variable. A tough restriction, but I think essential for scalable future coding. > A processor needs assembler, simple as that. Debugger is nice to have > but you can develop stuff without it, it just takes longer time. > C compiler is needed if you want more users. True. > With Xilinx 6-LUT, you can really make small 16-bit RISC machines > which is register file based. > Programming a register based CPU in assembler is much easier than a > stack machine. > I crafted a couple of years ago a 16-bit machine which could be as > small as 200 LUTs (4-LUT) but was around 300 LUTs in general. > It might be possible to do a 16-bit RISC at around 100 LUTs (6-LUT). > So the only benefit I see a stack machine has is more compact code. Yes , a good code density is possible. The use of code compression techniques by using an indirect jump vector table is a possible improvement in code density. Thus the following memory types could be defined. 1. Microcode. 4 bit instructions wide memory. 2. Jumpcode. n bit < 16 bit (n->16 map addresses). 3. Fullwidth. 16 bit. cheers jackoArticle: 138987
On Mar 17, 7:51=A0am, mopra <mohitpra...@gmail.com> wrote: > Hey thanks for your help but can you explain it a little more > elaborately. > > where should i use " copy myimage.jpg f:\ =A0"? =A0How to embed that in > the C code? > > Please help me in this regard. > > Regards, > Mohit If you have a Compact Disk reader/writer that attaches to a PC, one could use the DOS copy command like Antti mentioned to write your file to the compact disk. I have an IntelliFlash USB 6 to 1 memory reader/writer that lets me access the compact disk from my Windows Computer. .Article: 138988
Antti.Lukats@googlemail.com wrote: > On Mar 17, 5:09 pm, rickman <gnu...@gmail.com> wrote: >> On Mar 17, 9:58 am, "Antti.Luk...@googlemail.com" >> >> >> >> >> >> <Antti.Luk...@googlemail.com> wrote: >>> On Mar 17, 3:24 pm, Jacko <jackokr...@gmail.com> wrote: >>>> Hi >>>> Three cheers for Chuck Moore, and his hidden friend Keep Less ;-) >>>> Another zero operand CPUhttp://nibz.googlecode.com >>>> cheers jacko >>>> Now available in free licence of one core per ASIC/FPGA/CPLD, with two >>>> conditions. >>>> 1. A K Ring Technologies Logo must be printed atop the chip or close >>>> by on the PCB at any resolution. >>>> 2. Any documentation produced must acknowledge copyright and provide >>>> the URL. >>>> This licence is for those folks who do not like the BSD derived work >>>> restrictions. >>> the difference between zpu and nibz is that ZPU is supported >>> by GCC toolchain, while there are no tools to generate any >>> meaningful code for nibz >>> correct me if i am wrong >>> Antti >> Is that really the primary critera? I think you are right. But I >> have a similar CPU design that I expect to use on a project shortly >> and it will be programmed in assembly, but it will look a lot like >> Forth. I consider that to be close enough to a high level language. >> >> BTW, ZPU may have a GCC compiler, but without a debugger, is that >> really useful? There aren't many projects done in C that are debugged >> without an emulator. >> >> Rick- Hide quoted text - >> >> - Show quoted text - > > well assembler is GOOD if it exist :) > > so any soft-core with assembler is ok > but there is no assembler for nibz? so == useless. > no C, no assembler, == not possible to use :( > > a non working somesort of forht partially adopted > but not really tested does not count as development tool. > > a simple assembler would. > > I personally dont like C, but unfortunatly can not fully avoid it > either > > Antti Look at using a table driven user definable universal assembler b. Farmer. (I am back).Article: 138989
On Mar 18, 8:17=A0am, Goran_Bilski <goran.bil...@xilinx.com> wrote: > It might be possible to do a 16-bit RISC at around 100 LUTs (6-LUT). > So the only benefit I see a stack machine has is more compact code. So, are we going to see a Nano-Blaze for the 6-LUT Xilinx parts ? ;) -jgArticle: 138990
On Mar 17, 7:06=A0pm, Jacko <jackokr...@gmail.com> wrote: > > There is now a link on the instruction set page presenting an english > text description of the BO instruction. All other instructions follow > a similar symbology. Dude, you are really terrible at this. In one place you tell people about a CPU you designed with no specifics. Another place you post a link to a web page with very fuzzy descriptions of the instruction set that is not usable. Then here you post that you have added some more explanation, but no link. Are we supposed to search around to find the link to your web page again? I have no idea where to find it. I may not be very tactful, but I really am trying to help you, not be insulting. I hope it doesn't come off that way. RickArticle: 138991
Hi all: I use the Transceiver's RX_clk as PLL ref_inclk, but it reports error as below: Error: Clock input port inclk[0] of PLL "rec_clk62_pll:rec_clk62_pll| altpll:altpll_component|rec_clk62_pll_altpll:auto_generated|pll1" must be driven by a non-inverted input pin or another PLL, optionally through a Clock Control bloc. The transceiver is work in 10G date rate mode, and the clk frequency is 257.8125M How to resolve this problem, can you give any suggestions? Thank you very much for your help.Article: 138992
On Mar 17, 11:14=A0pm, reganirel...@gmail.com wrote: > Hey guys, > > I am working on an image processing FPGA design and plan to use an > embedded uB to control certain FPGA functions and perform some > preliminary analysis on processed image data written into a FIFO > peripheral. With any luck, the uB will be powerful enough to do > everything (analysis/calculation), but I have no experience with uB > and cannot really count on that. > > With further development of the recognition etc. I was considering > using a PowerPC CPU. If I did this, what would you recommend as the > best way to communicate between the uB and the PowerPC? I am just > learning embedded systems and any resources would be great. > > Thanks, > Gints excuse my ignorance here, but what is a uB?Article: 138993
Hal Murray wrote: >> BTW, ZPU may have a GCC compiler, but without a debugger, is that >> really useful? There aren't many projects done in C that are debugged >> without an emulator. > > I'm happy without a debugger, at least as long as the edit/compile/run > cycle is fast. Besides, a lot of the quirks I'm chasing are > timing issues where you need a scope to see what's going on. > > What do you use for a debugger when working on perl/python code? > For perl, Open Perl IDE http://open-perl-ide.sourceforge.net/ -urbArticle: 138994
"Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com> writes: > sure can use GCC as i already mentioned 4 posts ago :) > but it not always as good as good macro assembler I once wrote a microcode assembler *generator*. It would extract the operand specs from the Verilog HDL source and generate an assembler on the fly and then run it. The only two hardcoded ops were "org" and "label". The program was quite small, less than 200 lines of Common Lisp code. The assembler was built on top of Common Lisp so you also got the powerful Common Lisp macros and functions as a free feature. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 138995
On 18 Mar 2009 11:24:45 GMT, Albert van der Horst wrote: >The shallow stack of the transputer is lost on context >switches for equal priority task. Together with the >limitation where context switches could occur (only >on conditional jumps) this accounts for a very practical >design. (I would like to see a Ghz transputer with >all the modern chip design tricks.) Agreed wholeheartedly. The Transputer suffered badly because the technology that would make it effective (particularly, very fast serial links) was not available at the time; and the "prefix" mechanism was too wasteful of code space for comfort; but it had some brilliantly clever architectural ideas and I mourn its passing. Context switches could happen only at "scheduling points"; I think there were more of these than merely conditional branches. But whatever the detail, the basic idea of choosing only to switch context when the stack is empty is very cool. It requires very tight coupling among architecture, compiler and runtime executive, though. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 138996
In article <2cpur41022f7ug3ql1mknldgq88lebftju@4ax.com>, Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> wrote: >On Tue, 17 Mar 2009 03:46:55 -0500, Hal Murray wrote: > >>You can simplify the hardware a lot by pushing >>the stack overflow problem back to the compiler. >>That is, the stack has a fixed size. The compiler >>can't generate code that overflows that limit. > >OK. > >Getting the compiler to limit the stack size is >clearly possible (Transputer, anyone? it had a >3-register stack). But this is certain to >cause more memory references to escape to >memory. It's a compromise, like everything else. This 3 level stack already covered a great deal of formulas to calculcate. There is also a one byte instruction to fetch one of 16 memory locations, probably located in on chip ram. You may think of those as registers, and below that as explicit microcoding. > >>>Unfortunately the stack cache trashes multi-threading >>>performance, because there is so much context to swap. >[...] >>I don't understand that comment. Multi-threading requires >>separate stacks. That's just more RAM in the CPU > >Yes, but if a large swath of CPU register space is used >to cache the top-of-stack, then that cache must be >saved and restored on a context switch. You can only >provide a finite number of stack spaces in the CPU's >on-chip RAM, so at some point a context switch is >sure to entail a large penalty as some other thread's >stack cache must be evicted to main memory. > >Shallower on-chip stack cache means slower single- >thread performance, but faster context switch and >the opportunity to keep more threads' stacks >on-chip. Compromises again. The shallow stack of the transputer is lost on context switches for equal priority task. Together with the limitation where context switches could occur (only on conditional jumps) this accounts for a very practical design. (I would like to see a Ghz transputer with all the modern chip design tricks.) >-- >Jonathan Bromley, Consultant Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- like all pyramid schemes -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horstArticle: 138997
In article <ebc3acb0-d9d7-47aa-bc80-c120670cc03a@s20g2000yqh.googlegroups.com>, Antti.Lukats@googlemail.com <Antti.Lukats@googlemail.com> wrote: >On Mar 17, 5:09=A0pm, rickman <gnu...@gmail.com> wrote: >> On Mar 17, 9:58=A0am, "Antti.Luk...@googlemail.com" >> >> >> >> >> >> <Antti.Luk...@googlemail.com> wrote: >> > On Mar 17, 3:24=A0pm, Jacko <jackokr...@gmail.com> wrote: >> >> > > Hi >> >> > > Three cheers for Chuck Moore, and his hidden friend Keep Less ;-) >> >> > > Another zero operand CPUhttp://nibz.googlecode.com >> >> > > cheers jacko >> >> > > Now available in free licence of one core per ASIC/FPGA/CPLD, with tw= >o >> > > conditions. >> > > 1. A K Ring Technologies Logo must be printed atop the chip or close >> > > by on the PCB at any resolution. >> > > 2. Any documentation produced must acknowledge copyright and provide >> > > the URL. >> >> > > This licence is for those folks who do not like the BSD derived work >> > > restrictions. >> >> > the difference between zpu and nibz is that ZPU is supported >> > by GCC toolchain, while there are no tools to generate any >> > meaningful code for nibz >> >> > correct me if i am wrong >> >> > Antti >> >> Is that really the primary critera? =A0I think you are right. =A0But I >> have a similar CPU design that I expect to use on a project shortly >> and it will be programmed in assembly, but it will look a lot like >> Forth. =A0I consider that to be close enough to a high level language. >> >> BTW, ZPU may have a GCC compiler, but without a debugger, is that >> really useful? =A0There aren't many projects done in C that are debugged >> without an emulator. >> >> Rick- Hide quoted text - >> >> - Show quoted text - > >well assembler is GOOD if it exist :) > >so any soft-core with assembler is ok >but there is no assembler for nibz? so =3D=3D useless. >no C, no assembler, =3D=3D not possible to use :( I offer to write an assembler for euro 500 if it is of the complexity of an 68K, and for Euro 1000 if it is of the complexity of a DEC Alpha. >a non working somesort of forht partially adopted >but not really tested does not count as development tool. > >a simple assembler would. > >I personally dont like C, but unfortunatly can not fully avoid it >either > >Antti Now we are at it, would it not be a nice inroad for Forth if we were to generate the back end of gcc by Forth Assemblers? [My post-it fix-up assembler could be beefed up to do BEGIN NAME HASH PLONK REPEAT where NAME fetches the next word, HASH does a perfect HASH (and takes care of numbers) and PLONK is a single toggle of bits into memory. There is no conditional code, except for error checking. Now the output of a compiler can be trusted ... ] Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- like all pyramid schemes -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horstArticle: 138998
On Mar 18, 8:45=A0am, rickman <gnu...@gmail.com> wrote: > On Mar 17, 7:06=A0pm, Jacko <jackokr...@gmail.com> wrote: > > > > > There is now a link on the instruction set page presenting an english > > text description of the BO instruction. All other instructions follow > > a similar symbology. > > Dude, you are really terrible at this. =A0In one place you tell people > about a CPU you designed with no specifics. =A0Another place you post a > link to a web page with very fuzzy descriptions of the instruction set > that is not usable. =A0Then here you post that you have added some more > explanation, but no link. =A0Are we supposed to search around to find > the link to your web page again? =A0I have no idea where to find it. > > I may not be very tactful, but I really am trying to help you, not be > insulting. =A0I hope it doesn't come off that way. > > Rick You are so right... I looked (again) the nibz web downloaded the most promising document (tagged FEATURED!) did not understand much, scrolled to the end of the document.. where on the last line stands: ".... ummmm ...." guess this is what we all should be doing: ummmmmmm now, if we compare nibz to Mproz3 then 1 mproz3 is MUCH smaller 2 has superiour docu 3 has VERY simple assembler with source code (single file just invoke gcc to compile it) mproz3 is now available in VHDL form, and succesfully working in Silicon Blue FPGA :) so it doesnt matter how many times the nibz may be better, without documentation and tools its useless for anybody except the author. AnttiArticle: 138999
In comp.lang.forth Albert van der Horst <albert@spenarnc.xs4all.nl> wrote: > The shallow stack of the transputer is lost on context switches for > equal priority task. Together with the limitation where context > switches could occur (only on conditional jumps) this accounts for a > very practical design. Actually UNconditional jumps and lend (loop end). This was quite nice since you could prevent a context switch simply by ldc 0; cj L Andrew.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z