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 Mar 18, 4:48=A0am, wolahr <w...@volamp.com> wrote: > excuse my ignorance here, but what is a uB? microblazeArticle: 139001
\ FORTH Assembler for nibz \ \ Copyright (C) 2006,2007,2009 Free Software Foundation, Inc. \ This file is part of Gforth. \ Gforth is free software; you can redistribute it and/or \ modify it under the terms of the GNU General Public License \ as published by the Free Software Foundation, either version 3 \ of the License, or (at your option) any later version. \ This program is distributed in the hope that it will be useful, \ but WITHOUT ANY WARRANTY; without even the implied warranty of \ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the \ GNU General Public License for more details. \ You should have received a copy of the GNU General Public License \ along with this program. If not, see http://www.gnu.org/licenses/. \ \ Autor: Simon Jackson, BEng. \ \ Information: \ \ - Simple Assembler \ only forth definitions require asm/basic.fs also ASSEMBLER definitions require asm/target.fs HERE ( Begin ) \ The assembler is very simple. All 16 opcodes are \ defined immediate so they can be inlined into colon defs. \ primary opcode constant writers : BA 0 , ; immediate : FI 1 , ; immediate : RI 2 , ; immediate : SI 3 , ; immediate : DI 4 , ; immediate : FA 5 , ; immediate : RA 6 , ; immediate : SA 7 , ; immediate : BO 8 , ; immediate : FO 9 , ; immediate : RO 10 , ; immediate : SO 11 , ; immediate : SU 12 , ; immediate : FE 13 , ; immediate : RE 14 , ; immediate : SE 15 , ; immediate HERE SWAP - CR .( Length of Assembler: ) . .( Bytes ) CRArticle: 139002
Antti.Lukats@googlemail.com wrote: > On Mar 18, 8:45 am, rickman <gnu...@gmail.com> wrote: >> On Mar 17, 7:06 pm, 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. >> >> 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. > > Antti > > > > Antti - where did you find the mproz3 design? My google searches consistently turn up ftp://137.193.64.130/pub/mproz/mproz3.zip, but this server appears to be down. Do you know of a mirror for this. Also, from what I've been able to read, this design was originally a schematic design. Did you convert it? How does it compare to picoblaze in size, execution speed, and code density? -UrbArticle: 139003
On Mar 18, 2:36=A0pm, Jacko <jackokr...@gmail.com> wrote: > \ FORTH Assembler for nibz > \ > \ Copyright (C) 2006,2007,2009 Free Software Foundation, Inc. > > \ This file is part of Gforth. > > \ Gforth is free software; you can redistribute it and/or > \ modify it under the terms of the GNU General Public License > \ as published by the Free Software Foundation, either version 3 > \ of the License, or (at your option) any later version. > > \ This program is distributed in the hope that it will be useful, > \ but WITHOUT ANY WARRANTY; without even the implied warranty of > \ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. =A0See the > \ GNU General Public License for more details. > > \ You should have received a copy of the GNU General Public License > \ along with this program. If not, seehttp://www.gnu.org/licenses/. > \ > \ Autor: =A0 =A0 =A0 =A0 =A0Simon Jackson, BEng. > \ > \ Information: > \ > \ - Simple Assembler > > \ only forth definitions > > require asm/basic.fs > > =A0also ASSEMBLER definitions > > require asm/target.fs > > =A0HERE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ( Begin ) > > \ The assembler is very simple. All 16 opcodes are > \ defined immediate so they can be inlined into colon defs. > > \ primary opcode constant writers > > : BA 0 , ; immediate > : FI 1 , ; immediate > : RI 2 , ; immediate > : SI 3 , ; immediate > > : DI 4 , ; immediate > : FA 5 , ; immediate > : RA 6 , ; immediate > : SA 7 , ; immediate > > : BO 8 , ; immediate > : FO 9 , ; immediate > : RO 10 , ; immediate > : SO 11 , ; immediate > > : SU 12 , ; immediate > : FE 13 , ; immediate > : RE 14 , ; immediate > : SE 15 , ; immediate > > =A0HERE =A0SWAP - > =A0CR .( Length of Assembler: ) . .( Bytes ) CR Jacko, if you want other to understand, please make simple example: 1) test source file: TEST.ASM =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D inset asm op codes to write value 0xAA55 to IO address 0x2233 here =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2) provide some executable file such that: jackocompiler.exe TEST.ASM >TEST.BIN produces a code ready to load into FPGA block ram and when executed will write AA55 to address 2233 saying this is part of GForth... so what is ? you are part of GForth? nibz is? your assembler is? looking at your 2 LETTER code style, i have hard times to understand how to MOV OUTPORT, DATA we all belive what you do does makes sense for you but for others to use, ? no docu, no examples, no use.. eh i read you donation record, 0.00 so far eh my paypal account is at 0 too, otherwise i would donate the 42$ what i did estimate to be your total earnings... you do not need to try to rush so much, just do something properly.... B16 is also stack based soft-core, but it HAS an assembler please take a look, look how others have done assembler for stack machine, its ok to look, you dont have to todo everything from scratch AnttiArticle: 139004
Hi, rickman wrote: > I have been following the development of the ZPU, a zero operand > processor for FPGAs. The primary intent is to design a CPU that can > span a range of sizes from very space efficient to high speed while > being efficient at running C code. What do you expect from something that does not need operands or has only the operand "0" zero? It can not do much useful things - ok, it could heat the room it is inside. The purpose of a processor is to combine operational procedures with one or more operands. It does these operations one by one. If the CPU gets zero operands at all, it's very simple to make it high speed or space efficient. It could be targeted by every language that has a NOP operation. I know, I do understand this in the wrong way, but it had to be told anyway. Regards, -HelmarArticle: 139005
On Mar 18, 2:49=A0pm, Paul Urbanus <urbpub...@hotmail.com> wrote: > Antti.Luk...@googlemail.com wrote: > > On Mar 18, 8:45 am, rickman <gnu...@gmail.com> wrote: > >> On Mar 17, 7:06 pm, 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 mor= e > >> 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. > > > Antti > > Antti - where did you find the mproz3 design? > > My google searches consistently turn upftp://137.193.64.130/pub/mproz/mpr= oz3.zip, but this server appears to be > down. Do you know of a mirror for this. Also, from what I've been able > to read, this design was originally a schematic design. Did you convert i= t? > > How does it compare to picoblaze in size, execution speed, and code densi= ty? > > -Urb speed LOWER code density WORSE but: resources LESS addressing space LARGER the FTP seems to work and the VHDL translated version is now available, just uploaded http://groups.google.com/group/antti-brain/files?hl=3Den cheers AnttiArticle: 139006
Some of us have been a little frustrated by the hard-to-follow documentation of the nibz CPU. I thought it might be useful, as a comparison, to expose to public ridicule the documentation for a toy CPU I developed as fodder for some of our training courses. It doesn't yet have an assembler (sorry Antti!!!) but I hope you will agree that the docs are complete enough for you to write one should you so wish. I'm not trying to stir up interest in this CPU design, even though I think it's quite cute; there are far too many RISC soft-cores out there already. I just wanted to give an example of how you might go about documenting such a thing without putting in too much effort. Its instruction set is roughly of the same complexity as nibz, I think. http://www.oxfordbromley.plus.com/files/miniCPU/arch.pdf -- 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: 139007
On Mar 18, 3:29=A0pm, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com> wrote: > Some of us have been a little frustrated by the > hard-to-follow documentation of the nibz CPU. > I thought it might be useful, as a comparison, > to expose to public ridicule the documentation > for a toy CPU I developed as fodder for some of > our training courses. =A0It doesn't yet have an > assembler (sorry Antti!!!) but I hope you will > agree that the docs are complete enough for you > to write one should you so wish. > > I'm not trying to stir up interest in this CPU > design, even though I think it's quite cute; > there are far too many RISC soft-cores out there > already. =A0I just wanted to give an example of how > you might go about documenting such a thing without > putting in too much effort. =A0Its instruction set > is roughly of the same complexity as nibz, I think. > > http://www.oxfordbromley.plus.com/files/miniCPU/arch.pdf > -- > 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. Hi it is defenetly interesting already! because it has human readable documentation and creating an assembler based on the docu can be accomplished in less than an hour AnttiArticle: 139008
Hi, I have a design with multiple clock boundary crossings. I use the double buffering method for all clock boundary crossings. I am using Xilinx ISE to compile my code and would like to know if the following false path setting is correct for my design: I have four main clocks, dsp_clk, dsp_clk_div2, hkb_clk and adc_two_clk. All of the crossings occur between dsp_clk and the others. These are the clock signals from the output of port CLK0 of their respective DCM TIMESPEC TS_dsp_clk_to_dsp_clk_div2 = FROM "clock_manager_dcm_dsp_clk_0" TO "clock_manager_dcm_dsp_clk_div2_0" TIG; TIMESPEC TS_dsp_clk_to_hkb_clk = FROM "clock_manager_dcm_dsp_clk_0" TO "clock_manager_dcm_hkb_clk_0" TIG; TIMESPEC TS_dsp_clk_adc_two_clk = FROM "clock_manager_dcm_dsp_clk_0" TO "clock_manager_dcm_adc_two_clk_0" TIG; Thanks, AmishArticle: 139009
On 18 Mar, 11:48, "Antti.Luk...@googlemail.com" <Antti.Luk...@googlemail.com> wrote: > 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 The umm does make sense in terms of what the document was describing. There is now a featured download of the instruction set at http://nibz.googlecode.com > 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) And has a self modifying code tendancy. > mproz3 is now available in VHDL form, and succesfully working in > Silicon Blue FPGA :) Excellent. > so it doesnt matter how many times the nibz may be better, without > documentation > and tools its useless for anybody except the author. In general true. cheers jackoArticle: 139010
On Mar 18, 6:06=A0am, Helmar <hel...@gmail.com> wrote: > What do you expect from something that does not need operands or has > only the operand "0" zero? It can not do much useful things - ok, it > could heat the room it is inside. Zero operand just means that the top of the stack is the implied operand for most instructions. It means that a register decoding phase is not needed in the execution of instructions because the operand is the stack. Instead of having to decode which registers are gated for input and which register is gated for output, and set up the gates to the ALU as some of the steps in executing an instruction the path to operands is hard wired because it is the top of the stack. So there are no operands to decode. It is not very clever to try to convince people that it means that there are no arguements at all and thefore all it can do is NOP. It certainly does not mean that it cannot do useful things. After all some languages like Forth are also zero operand because they use the top of a parameter stack. Parameters are still needed for branching and for literals but they are not operand fields for registers that require a decoding phase hence the name zero operand. Some people will declare that programming a register machine is just easiter than programming a stack machine. Their argument is that the compiler they use makes it easy or that they can stay at a higher level of abstraction. Some people will declare that programming a stack machine is just easier than programming a register machine. Their argument is that their compiler and language is simpler and smaller and doesn't need all that complicated register stuff. They may say that to program a register machine people need complex smart compilers to hide the real complexity under the hood and they prefer something simpler. And all that is mostly a matter of whether they are thinking of software in a style used on register machines or a style used on stack machines or virtual stack machines. If you use C then you like C hardware and C software and may think stack languages or stack hardware is harder for you to deal with. If you use Forth then you may think stack software and stack hardware is a lot simpler and easier to deal with than bigger more complex tools and platforms. People choose Forth for embedded work to get smaller, cheaper, and lower power solutions to problems than those available with the bigger more expensive, more complex hardware and software. Which is easier depends entirely on what you know and the problem at hand. > The purpose of a processor is to combine operational procedures with > one or more operands. Yes of course. The idea of 'zero operand' is that the arguments, operands, are on the stacks. It's just silly and stupid to argue that it means that there are no arguments and thus nothing useful. > It does these operations one by one. > If the CPU gets zero operands at all, it's very simple to make it high > speed or space efficient. And it may be easy to port software far more compact and space efficient than register machine native code especially when the design needs inlining and loop unrolling to ger around pipeline or cache problems. The idea is to also reduce power consumption and resources required by the design. The idea is to be able to execute more compact stack based code than register based code to further reduce cost and power consumption by reducing memory use. The idea is to make the CPU easier to program and more efficient with simple software rather than demanding the biggest and most complex development tools. > It could be targeted by every language that > has a NOP operation. That's just insulting and dumb. Zero operand does not mean NOP only. ;-) That's a new Forth-hater sound-bite, Forth and stacks are only good for doing NOPs. Only the most ignorant will believe it. ;-) > I know, I do understand this in the wrong way, but it had to be told > anyway. It did not have to be told! Best WishesArticle: 139011
On Mar 18, 9:44=A0am, axr0284 <axr0...@yahoo.com> wrote: > Hi, > =A0I have a design with multiple clock boundary crossings. I use the > double buffering method for all clock boundary crossings. I am using > Xilinx ISE to compile my code and would like to know if the following > false path setting is correct for my design: > I have four main clocks, dsp_clk, dsp_clk_div2, hkb_clk and > adc_two_clk. > All of the crossings occur between dsp_clk and the others. > > These are the clock signals from the output of port CLK0 of their > respective DCM > > TIMESPEC TS_dsp_clk_to_dsp_clk_div2 =3D FROM > "clock_manager_dcm_dsp_clk_0" TO "clock_manager_dcm_dsp_clk_div2_0" > TIG; > TIMESPEC TS_dsp_clk_to_hkb_clk =3D FROM "clock_manager_dcm_dsp_clk_0" TO > "clock_manager_dcm_hkb_clk_0" TIG; > TIMESPEC TS_dsp_clk_adc_two_clk =3D FROM "clock_manager_dcm_dsp_clk_0" > TO "clock_manager_dcm_adc_two_clk_0" TIG; > > Thanks, > Amish Personally, I think it is much better to explicitly state the signals that cross boundaries and declare them to be multi-cycle (or false path if you prefer). That way one can cross check between the contraints and real code to verify that yes indeed this domain is handled properly by design. [1] By making the blanket statement all crossing between clock domain X and clock domain Y are false paths (as it appears that to me that you're doing) you're immediately assuming that you've properly implemented the domain crossing logic correctly under all of the following - Now and forever into the future - No matter how many design iterations your code goes through - No matter who ever makes a change to that code. Such clock domain crossing logic should be proven to be correct, not assumed. Kevin Jennings [1] There are other aspects to this logic that need to be handled like guaranteeing any handshake signals properly line up with the data, but let's not get into that here, just limit this to double buffering of async signals to get them synced to a clock.Article: 139012
On Mar 17, 10:17=A0pm, 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. > > 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 Bilski too bad the S-6 is delaying sooooo looooong so others than the few EA companies can develop code for S-6/V-6 LUT6 hopefully means also SRL64 what would be cool, but eh it should be now a few months til the 11.1 release so the mortals will see the spec too then AnttiArticle: 139013
Hi Jeff, On Mar 18, 11:14=A0am, Jeff Fox <f...@ultratechnology.com> wrote: > On Mar 18, 6:06=A0am, Helmar <hel...@gmail.com> wrote: > > > What do you expect from something that does not need operands or has > > only the operand "0" zero? It can not do much useful things - ok, it > > could heat the room it is inside. > > Zero operand just means that the top of the stack is the implied > operand for most instructions. =A0It means that a register decoding > phase is not needed in the execution of instructions because the > operand is the stack. OK, same then: a TOS can not be the only operand. You very probably mean of course that the stack contains the operands. This is indeed clever but does not mean "zero operands". Regarding this "register decoding phase" - well, you have to "decode" it if you make the distinction between "operation" and "operand". But if you see "ADD A, 1" as a different operation than "ADD B,1", you do not have any "phase" in front of knowing what operation is needed. It simply could be two different operations. So if you term a "stack" layout based thing "zero operand" you could also call every "register" based layout to be "zero operand", as far as every register has its own implementation of "ADD". > Instead of having to decode which registers are gated for input > and which register is gated for output, and set up the gates to > the ALU as some of the steps in executing an instruction the path > to operands is hard wired because it is the top of the stack. =A0So > there are no operands to decode. There are still operands to decode. It might be the stack is somewhere in memory or it's something like a few registers without possibility to address them. There are still operands and they need to be addressed and as that also "decoded" (even if this is not needed by the symbolical instruction representation called "machine code"). > It is not very clever to try to convince people that it means that > there are no arguements at all and thefore all it can do is NOP. Well, without further instruction, everybody will think it is so. > It certainly does not mean that it cannot do useful things. =A0After all > some languages like Forth are also zero operand because they use > the top of a parameter stack. =A0Parameters are still needed for > branching and for literals but they are not operand fields for > registers that require a decoding phase hence the name zero operand. > > Some people will declare that programming a register machine is > just easiter than programming a stack machine. =A0Their argument > is that the compiler they use makes it easy or that they can > stay at a higher level of abstraction. ;) OK, that declarations does not interest me, as far as even mobile phones start to be implemented using x86 technology... > Some people will declare that programming a stack machine is just > easier than programming a register machine. =A0Their argument is that > their compiler and language is simpler and smaller and doesn't > need all that complicated register stuff. =A0They may say that to > program a register machine people need complex smart > compilers to hide the real complexity under the hood and they > prefer something simpler. OK, in Forth: : foo dup ; : foo1 ! ; : foo2 swap foo tuck foo1 ; This now looks like a completely "useless" complicated sequence, nobody would write this way. The truth is, that the more you use that nice "symbolic" stuff in Forth, the more that "useless" complicated sequences occur in output. If you want to allow your users to use that symbolic stuff - and you want to avoid too "useless" operations, even the stack based compiler- thing has to optimize. Except for few, simple loophole-optimizations, the stack based design of a processor does not help with it. The compiler gets at least as complicated as every other - or maybe even more complex (this would have to be done first I think). > And all that is mostly a matter of whether they are thinking of > software in a style used on register machines or a style used > on stack machines or virtual stack machines. =A0If you use C > then you like C hardware and C software and may think stack > languages or stack hardware is harder for you to deal with. > > If you use Forth then you may think stack software and stack > hardware is a lot simpler and easier to deal with than bigger > more complex tools and platforms. =A0 People choose Forth > for embedded work to get smaller, cheaper, and lower > power solutions to problems than those available with the > bigger more expensive, more complex hardware and > software. OK. > Which is easier depends entirely on what you know and > the problem at hand. Sure? I mean the "problem at hand"? It would be interesting to know if there are differences depending on the problem. > > The purpose of a processor is to combine operational procedures with > > one or more operands. > > Yes of course. =A0The idea of 'zero operand' is that the arguments, > operands, are on the stacks. =A0It's just silly and stupid to argue > that > it means that there are no arguments and thus nothing useful. > > > It does these operations one by one. > > If the CPU gets zero operands at all, it's very simple to make it high > > speed or space efficient. > > And it may be easy to port software far more compact and space > efficient than register machine native code especially when the design > needs inlining and loop unrolling to ger around pipeline or cache > problems. > > The idea is to also reduce power consumption and resources > required by the design. =A0The idea is to be able to execute more > compact stack based code than register based code to further > reduce cost and power consumption by reducing memory use. > The idea is to make the CPU easier to program and more > efficient with simple software rather than demanding the > biggest and most complex development tools. > > > It could be targeted by every language that > > has a NOP operation. > > That's just insulting and dumb. =A0Zero operand does not mean > NOP only. ;-) =A0 That's a new Forth-hater sound-bite, Forth > and stacks are only good for doing NOPs. Only the most > ignorant will believe it. ;-) ;) Regards, -HelmarArticle: 139014
On Mar 18, 6:36=A0pm, Helmar <hel...@gmail.com> wrote: > Hi Jeff, > > On Mar 18, 11:14=A0am, Jeff Fox <f...@ultratechnology.com> wrote: > > > On Mar 18, 6:06=A0am, Helmar <hel...@gmail.com> wrote: > > > > What do you expect from something that does not need operands or has > > > only the operand "0" zero? It can not do much useful things - ok, it > > > could heat the room it is inside. > > > Zero operand just means that the top of the stack is the implied > > operand for most instructions. =A0It means that a register decoding > > phase is not needed in the execution of instructions because the > > operand is the stack. > > OK, same then: a TOS can not be the only operand. You very probably > mean of course that the stack contains the operands. This is indeed > clever but does not mean "zero operands". Regarding this "register > decoding phase" - well, you have to "decode" it if you make the > distinction between "operation" and "operand". But if you see "ADD A, > 1" as a different operation than "ADD B,1", you do not have any > "phase" in front of knowing what operation is needed. It simply could > be two different operations. So if you term a "stack" layout based > thing "zero operand" you could also call every "register" based layout > to be "zero operand", as far as every register has its own > implementation of "ADD". > > > Instead of having to decode which registers are gated for input > > and which register is gated for output, and set up the gates to > > the ALU as some of the steps in executing an instruction the path > > to operands is hard wired because it is the top of the stack. =A0So > > there are no operands to decode. > > There are still operands to decode. It might be the stack is somewhere > in memory or it's something like a few registers without possibility > to address them. There are still operands and they need to be > addressed and as that also "decoded" (even if this is not needed by > the symbolical instruction representation called "machine code"). > > > It is not very clever to try to convince people that it means that > > there are no arguements at all and thefore all it can do is NOP. > > Well, without further instruction, everybody will think it is so. > > > It certainly does not mean that it cannot do useful things. =A0After al= l > > some languages like Forth are also zero operand because they use > > the top of a parameter stack. =A0Parameters are still needed for > > branching and for literals but they are not operand fields for > > registers that require a decoding phase hence the name zero operand. > > > Some people will declare that programming a register machine is > > just easiter than programming a stack machine. =A0Their argument > > is that the compiler they use makes it easy or that they can > > stay at a higher level of abstraction. > > ;) OK, that declarations does not interest me, as far as even mobile > phones start to be implemented using x86 technology... > > > Some people will declare that programming a stack machine is just > > easier than programming a register machine. =A0Their argument is that > > their compiler and language is simpler and smaller and doesn't > > need all that complicated register stuff. =A0They may say that to > > program a register machine people need complex smart > > compilers to hide the real complexity under the hood and they > > prefer something simpler. > > OK, in Forth: > > : foo dup ; > : foo1 ! ; > : foo2 swap foo tuck foo1 ; > > This now looks like a completely "useless" complicated sequence, > nobody would write this way. > The truth is, that the more you use that nice "symbolic" stuff in > Forth, the more that "useless" complicated sequences occur in output. > If you want to allow your users to use that symbolic stuff - and you > want to avoid too "useless" operations, even the stack based compiler- > thing has to optimize. Except for few, simple loophole-optimizations, > the stack based design of a processor does not help with it. The > compiler gets at least as complicated as every other - or maybe even > more complex (this would have to be done first I think). > > > And all that is mostly a matter of whether they are thinking of > > software in a style used on register machines or a style used > > on stack machines or virtual stack machines. =A0If you use C > > then you like C hardware and C software and may think stack > > languages or stack hardware is harder for you to deal with. > > > If you use Forth then you may think stack software and stack > > hardware is a lot simpler and easier to deal with than bigger > > more complex tools and platforms. =A0 People choose Forth > > for embedded work to get smaller, cheaper, and lower > > power solutions to problems than those available with the > > bigger more expensive, more complex hardware and > > software. > > OK. > > > Which is easier depends entirely on what you know and > > the problem at hand. > > Sure? I mean the "problem at hand"? It would be interesting to know if > there are differences depending on the problem. > > > > > > > > The purpose of a processor is to combine operational procedures with > > > one or more operands. > > > Yes of course. =A0The idea of 'zero operand' is that the arguments, > > operands, are on the stacks. =A0It's just silly and stupid to argue > > that > > it means that there are no arguments and thus nothing useful. > > > > It does these operations one by one. > > > If the CPU gets zero operands at all, it's very simple to make it hig= h > > > speed or space efficient. > > > And it may be easy to port software far more compact and space > > efficient than register machine native code especially when the design > > needs inlining and loop unrolling to ger around pipeline or cache > > problems. > > > The idea is to also reduce power consumption and resources > > required by the design. =A0The idea is to be able to execute more > > compact stack based code than register based code to further > > reduce cost and power consumption by reducing memory use. > > The idea is to make the CPU easier to program and more > > efficient with simple software rather than demanding the > > biggest and most complex development tools. > > > > It could be targeted by every language that > > > has a NOP operation. > > > That's just insulting and dumb. =A0Zero operand does not mean > > NOP only. ;-) =A0 That's a new Forth-hater sound-bite, Forth > > and stacks are only good for doing NOPs. Only the most > > ignorant will believe it. ;-) > > ;) > > Regards, > -Helmar- Hide quoted text - > > - Show quoted text - Jeff & Helmar another holy war? there are pro and contra for everything. what is sure is that as of today the register based (or maybe 0 register ones like mproz3) small FPGA oriented soft-core processors are EASIER to deal with then those that are forth like and stack based . be the reason inbetween the ears, or in bad documentation or missing tools, whatever. Thing is non-stack based small soft-cores are easier for normal FPGA users . I would not mind if it would be the other way around, but it isnt. So some forth guy could make some effort to describe and document the use of some small SoC that uses stack - based core and is not programmed in C (that is some thing else then ZPU what is stack cpu with GCC support) Antti (hm i should look the B16.. again )Article: 139015
On Mar 18, 9:06=A0am, Helmar <hel...@gmail.com> wrote: > What do you expect from something that does not need operands or has Studying first-year computer science (machine architecture) might be helpful to you, since this is very standard terminology. Of course relatively few people have worked on zero-operand ISAs but I guess most people in this NG have worked extensively with 1- and 2-operand machines, and probably 3-operand also.Article: 139016
On Mar 18, 8:36=A0am, Jacko <jackokr...@gmail.com> wrote: > \ FORTH Assembler for nibz > \ > \ Copyright (C) 2006,2007,2009 Free Software Foundation, Inc. > > \ This file is part of Gforth. > > \ Gforth is free software; you can redistribute it and/or > \ modify it under the terms of the GNU General Public License > \ as published by the Free Software Foundation, either version 3 > \ of the License, or (at your option) any later version. > > \ This program is distributed in the hope that it will be useful, > \ but WITHOUT ANY WARRANTY; without even the implied warranty of > \ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. =A0See the > \ GNU General Public License for more details. > > \ You should have received a copy of the GNU General Public License > \ along with this program. If not, seehttp://www.gnu.org/licenses/. > \ > \ Autor: =A0 =A0 =A0 =A0 =A0Simon Jackson, BEng. > \ > \ Information: > \ > \ - Simple Assembler > > \ only forth definitions > > require asm/basic.fs > > =A0also ASSEMBLER definitions > > require asm/target.fs > > =A0HERE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ( Begin ) > > \ The assembler is very simple. All 16 opcodes are > \ defined immediate so they can be inlined into colon defs. > > \ primary opcode constant writers > > : BA 0 , ; immediate > : FI 1 , ; immediate > : RI 2 , ; immediate > : SI 3 , ; immediate > > : DI 4 , ; immediate > : FA 5 , ; immediate > : RA 6 , ; immediate > : SA 7 , ; immediate > > : BO 8 , ; immediate > : FO 9 , ; immediate > : RO 10 , ; immediate > : SO 11 , ; immediate > > : SU 12 , ; immediate > : FE 13 , ; immediate > : RE 14 , ; immediate > : SE 15 , ; immediate > > =A0HERE =A0SWAP - > =A0CR .( Length of Assembler: ) . .( Bytes ) CR What instruction is a CALL? How do you specify the address? How do you specify literal data? RickArticle: 139017
On Mar 18, 12:51=A0pm, zwsdot...@gmail.com wrote: > On Mar 18, 9:06=A0am, Helmar <hel...@gmail.com> wrote: > > > What do you expect from something that does not need operands or has > > Studying first-year computer science (machine architecture) might be > helpful to you, since this is very standard terminology. Of course > relatively few people have worked on zero-operand ISAs but I guess > most people in this NG have worked extensively with 1- and 2-operand > machines, and probably 3-operand also. Obvious is that I only studied it the first year (it was in conflict with my "philosophy"-schedules). And in this case it did not help, since I studied "formal logic" after it. You should be sure that I know that 2-operand machines would be acceptable for me, while I do have problems with 1-operand too (may it be zero "0" or not). I btw. can not even remember that some operations had no operands at all - except maybe something like NOP, while even this had "operands" like the program counter that would be increased. That far, be nice not rude, -HelmarArticle: 139018
Hi, I want to generate a random number in a FPGA chip and in a natural way it leads to a famous paper Xilinx XAPP052 authored by Peter Alfke: "Efficient Shift Register, LFSR Counters, and Long Pseudo-Random Sequence Generators". I have two problems with the note. 1. I don't understand "Divide-by-5 to 16 counter". I appreciate if someone explain the Table 2 and Figure 2 in more details. 2. In Figure 5, there is an equation: (Q3 xnor Q4) xor (Q1 and Q2 and Q3 and Q4). (Q3 xnor Q4) is required to generate 4-bit LFSR counter. (Q1 and Q2 and Q3 and Q4) is used to avoid a dead-lock situation from happening when Q1-Q4 = '1'. Now the 4-bit LFSR counter dead-lock situation should be extended to any bits long LFSR counter if 2 elements XNOR operation is needed. Especially in Figure 5 for 63-bit LFSR counter. When all 63-bits are '1', it would be dead-locked into the all '1' position, because (Q62 xnor Q63) = '1' if both Q63 and Q62 are '1'. But the situation is excluded into the equation in Figure 5. In another words, if a seed data is closing or equal to all '1' situation, the LFSR is a shorter random number generator than its claim of a 63-bit length generator. There is no way to exactly know if a seed data is closing to all '1' situation. We can add logic equation as 4-bit situation does as follows: (Q62 xnor Q63) xor (Q1 and Q2 and ... and Q63). There is a new question: If there is a more clever idea to do the same things to avoid the 63-bit dead-lock situation from happening? WengArticle: 139019
What are you talking about. I saw your other post and realized immediately that you were making a joke. I saw Jeff's reply and realized that he misunderstood you. Then I saw this reply and realized that I was wrong and you ***WEREN'T KIDDING***!!! Man, some people just don't get it. Some of the stuff you say below is either from lala land or you are still pulling people's legs. So are you for real? Is your real name, Amelia Bedelia? Rick On Mar 18, 12:36=A0pm, Helmar <hel...@gmail.com> wrote: > Hi Jeff, > > On Mar 18, 11:14=A0am, Jeff Fox <f...@ultratechnology.com> wrote: > > > On Mar 18, 6:06=A0am, Helmar <hel...@gmail.com> wrote: > > > > What do you expect from something that does not need operands or has > > > only the operand "0" zero? It can not do much useful things - ok, it > > > could heat the room it is inside. > > > Zero operand just means that the top of the stack is the implied > > operand for most instructions. =A0It means that a register decoding > > phase is not needed in the execution of instructions because the > > operand is the stack. > > OK, same then: a TOS can not be the only operand. You very probably > mean of course that the stack contains the operands. This is indeed > clever but does not mean "zero operands". Regarding this "register > decoding phase" - well, you have to "decode" it if you make the > distinction between "operation" and "operand". But if you see "ADD A, > 1" as a different operation than "ADD B,1", you do not have any > "phase" in front of knowing what operation is needed. It simply could > be two different operations. So if you term a "stack" layout based > thing "zero operand" you could also call every "register" based layout > to be "zero operand", as far as every register has its own > implementation of "ADD". > > > Instead of having to decode which registers are gated for input > > and which register is gated for output, and set up the gates to > > the ALU as some of the steps in executing an instruction the path > > to operands is hard wired because it is the top of the stack. =A0So > > there are no operands to decode. > > There are still operands to decode. It might be the stack is somewhere > in memory or it's something like a few registers without possibility > to address them. There are still operands and they need to be > addressed and as that also "decoded" (even if this is not needed by > the symbolical instruction representation called "machine code"). > > > It is not very clever to try to convince people that it means that > > there are no arguements at all and thefore all it can do is NOP. > > Well, without further instruction, everybody will think it is so. > > > It certainly does not mean that it cannot do useful things. =A0After al= l > > some languages like Forth are also zero operand because they use > > the top of a parameter stack. =A0Parameters are still needed for > > branching and for literals but they are not operand fields for > > registers that require a decoding phase hence the name zero operand. > > > Some people will declare that programming a register machine is > > just easiter than programming a stack machine. =A0Their argument > > is that the compiler they use makes it easy or that they can > > stay at a higher level of abstraction. > > ;) OK, that declarations does not interest me, as far as even mobile > phones start to be implemented using x86 technology... > > > Some people will declare that programming a stack machine is just > > easier than programming a register machine. =A0Their argument is that > > their compiler and language is simpler and smaller and doesn't > > need all that complicated register stuff. =A0They may say that to > > program a register machine people need complex smart > > compilers to hide the real complexity under the hood and they > > prefer something simpler. > > OK, in Forth: > > : foo dup ; > : foo1 ! ; > : foo2 swap foo tuck foo1 ; > > This now looks like a completely "useless" complicated sequence, > nobody would write this way. > The truth is, that the more you use that nice "symbolic" stuff in > Forth, the more that "useless" complicated sequences occur in output. > If you want to allow your users to use that symbolic stuff - and you > want to avoid too "useless" operations, even the stack based compiler- > thing has to optimize. Except for few, simple loophole-optimizations, > the stack based design of a processor does not help with it. The > compiler gets at least as complicated as every other - or maybe even > more complex (this would have to be done first I think). > > > And all that is mostly a matter of whether they are thinking of > > software in a style used on register machines or a style used > > on stack machines or virtual stack machines. =A0If you use C > > then you like C hardware and C software and may think stack > > languages or stack hardware is harder for you to deal with. > > > If you use Forth then you may think stack software and stack > > hardware is a lot simpler and easier to deal with than bigger > > more complex tools and platforms. =A0 People choose Forth > > for embedded work to get smaller, cheaper, and lower > > power solutions to problems than those available with the > > bigger more expensive, more complex hardware and > > software. > > OK. > > > Which is easier depends entirely on what you know and > > the problem at hand. > > Sure? I mean the "problem at hand"? It would be interesting to know if > there are differences depending on the problem. > > > > > > The purpose of a processor is to combine operational procedures with > > > one or more operands. > > > Yes of course. =A0The idea of 'zero operand' is that the arguments, > > operands, are on the stacks. =A0It's just silly and stupid to argue > > that > > it means that there are no arguments and thus nothing useful. > > > > It does these operations one by one. > > > If the CPU gets zero operands at all, it's very simple to make it hig= h > > > speed or space efficient. > > > And it may be easy to port software far more compact and space > > efficient than register machine native code especially when the design > > needs inlining and loop unrolling to ger around pipeline or cache > > problems. > > > The idea is to also reduce power consumption and resources > > required by the design. =A0The idea is to be able to execute more > > compact stack based code than register based code to further > > reduce cost and power consumption by reducing memory use. > > The idea is to make the CPU easier to program and more > > efficient with simple software rather than demanding the > > biggest and most complex development tools. > > > > It could be targeted by every language that > > > has a NOP operation. > > > That's just insulting and dumb. =A0Zero operand does not mean > > NOP only. ;-) =A0 That's a new Forth-hater sound-bite, Forth > > and stacks are only good for doing NOPs. Only the most > > ignorant will believe it. ;-) > > ;) > > Regards, > -HelmarArticle: 139020
Or you could use something like cgen (http://sourceware.org/cgen/), then you can have your assembler and simulator generated automatically for you (no reason why this couldn't also be extended to generating GCC backend and prototype HDL too). JonArticle: 139021
You want an answer from *this* writing below? Are you kidding? -Helmar On Mar 18, 1:07=A0pm, rickman <gnu...@gmail.com> wrote: > What are you talking about. =A0I saw your other post and realized > immediately that you were making a joke. =A0I saw Jeff's reply and > realized that he misunderstood you. =A0Then I saw this reply and > realized that I was wrong and you ***WEREN'T KIDDING***!!! > > Man, some people just don't get it. =A0Some of the stuff you say below > is either from lala land or you are still pulling people's legs. > > So are you for real? =A0Is your real name, Amelia Bedelia? > > Rick > > On Mar 18, 12:36=A0pm, Helmar <hel...@gmail.com> wrote: > > > > > Hi Jeff, > > > On Mar 18, 11:14=A0am, Jeff Fox <f...@ultratechnology.com> wrote: > > > > On Mar 18, 6:06=A0am, Helmar <hel...@gmail.com> wrote: > > > > > What do you expect from something that does not need operands or ha= s > > > > only the operand "0" zero? It can not do much useful things - ok, i= t > > > > could heat the room it is inside. > > > > Zero operand just means that the top of the stack is the implied > > > operand for most instructions. =A0It means that a register decoding > > > phase is not needed in the execution of instructions because the > > > operand is the stack. > > > OK, same then: a TOS can not be the only operand. You very probably > > mean of course that the stack contains the operands. This is indeed > > clever but does not mean "zero operands". Regarding this "register > > decoding phase" - well, you have to "decode" it if you make the > > distinction between "operation" and "operand". But if you see "ADD A, > > 1" as a different operation than "ADD B,1", you do not have any > > "phase" in front of knowing what operation is needed. It simply could > > be two different operations. So if you term a "stack" layout based > > thing "zero operand" you could also call every "register" based layout > > to be "zero operand", as far as every register has its own > > implementation of "ADD". > > > > Instead of having to decode which registers are gated for input > > > and which register is gated for output, and set up the gates to > > > the ALU as some of the steps in executing an instruction the path > > > to operands is hard wired because it is the top of the stack. =A0So > > > there are no operands to decode. > > > There are still operands to decode. It might be the stack is somewhere > > in memory or it's something like a few registers without possibility > > to address them. There are still operands and they need to be > > addressed and as that also "decoded" (even if this is not needed by > > the symbolical instruction representation called "machine code"). > > > > It is not very clever to try to convince people that it means that > > > there are no arguements at all and thefore all it can do is NOP. > > > Well, without further instruction, everybody will think it is so. > > > > It certainly does not mean that it cannot do useful things. =A0After = all > > > some languages like Forth are also zero operand because they use > > > the top of a parameter stack. =A0Parameters are still needed for > > > branching and for literals but they are not operand fields for > > > registers that require a decoding phase hence the name zero operand. > > > > Some people will declare that programming a register machine is > > > just easiter than programming a stack machine. =A0Their argument > > > is that the compiler they use makes it easy or that they can > > > stay at a higher level of abstraction. > > > ;) OK, that declarations does not interest me, as far as even mobile > > phones start to be implemented using x86 technology... > > > > Some people will declare that programming a stack machine is just > > > easier than programming a register machine. =A0Their argument is that > > > their compiler and language is simpler and smaller and doesn't > > > need all that complicated register stuff. =A0They may say that to > > > program a register machine people need complex smart > > > compilers to hide the real complexity under the hood and they > > > prefer something simpler. > > > OK, in Forth: > > > : foo dup ; > > : foo1 ! ; > > : foo2 swap foo tuck foo1 ; > > > This now looks like a completely "useless" complicated sequence, > > nobody would write this way. > > The truth is, that the more you use that nice "symbolic" stuff in > > Forth, the more that "useless" complicated sequences occur in output. > > If you want to allow your users to use that symbolic stuff - and you > > want to avoid too "useless" operations, even the stack based compiler- > > thing has to optimize. Except for few, simple loophole-optimizations, > > the stack based design of a processor does not help with it. The > > compiler gets at least as complicated as every other - or maybe even > > more complex (this would have to be done first I think). > > > > And all that is mostly a matter of whether they are thinking of > > > software in a style used on register machines or a style used > > > on stack machines or virtual stack machines. =A0If you use C > > > then you like C hardware and C software and may think stack > > > languages or stack hardware is harder for you to deal with. > > > > If you use Forth then you may think stack software and stack > > > hardware is a lot simpler and easier to deal with than bigger > > > more complex tools and platforms. =A0 People choose Forth > > > for embedded work to get smaller, cheaper, and lower > > > power solutions to problems than those available with the > > > bigger more expensive, more complex hardware and > > > software. > > > OK. > > > > Which is easier depends entirely on what you know and > > > the problem at hand. > > > Sure? I mean the "problem at hand"? It would be interesting to know if > > there are differences depending on the problem. > > > > > The purpose of a processor is to combine operational procedures wit= h > > > > one or more operands. > > > > Yes of course. =A0The idea of 'zero operand' is that the arguments, > > > operands, are on the stacks. =A0It's just silly and stupid to argue > > > that > > > it means that there are no arguments and thus nothing useful. > > > > > It does these operations one by one. > > > > If the CPU gets zero operands at all, it's very simple to make it h= igh > > > > speed or space efficient. > > > > And it may be easy to port software far more compact and space > > > efficient than register machine native code especially when the desig= n > > > needs inlining and loop unrolling to ger around pipeline or cache > > > problems. > > > > The idea is to also reduce power consumption and resources > > > required by the design. =A0The idea is to be able to execute more > > > compact stack based code than register based code to further > > > reduce cost and power consumption by reducing memory use. > > > The idea is to make the CPU easier to program and more > > > efficient with simple software rather than demanding the > > > biggest and most complex development tools. > > > > > It could be targeted by every language that > > > > has a NOP operation. > > > > That's just insulting and dumb. =A0Zero operand does not mean > > > NOP only. ;-) =A0 That's a new Forth-hater sound-bite, Forth > > > and stacks are only good for doing NOPs. Only the most > > > ignorant will believe it. ;-) > > > ;) > > > Regards, > > -HelmarArticle: 139022
On 18 Mar, 16:59, rickman <gnu...@gmail.com> wrote: > On Mar 18, 8:36 am, Jacko <jackokr...@gmail.com> wrote: > > > > > \ FORTH Assembler for nibz > > \ > > \ Copyright (C) 2006,2007,2009 Free Software Foundation, Inc. > > > \ This file is part of Gforth. > > > \ Gforth is free software; you can redistribute it and/or > > \ modify it under the terms of the GNU General Public License > > \ as published by the Free Software Foundation, either version 3 > > \ of the License, or (at your option) any later version. > > > \ This program is distributed in the hope that it will be useful, > > \ but WITHOUT ANY WARRANTY; without even the implied warranty of > > \ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > \ GNU General Public License for more details. > > > \ You should have received a copy of the GNU General Public License > > \ along with this program. If not, seehttp://www.gnu.org/licenses/. > > \ > > \ Autor: Simon Jackson, BEng. > > \ > > \ Information: > > \ > > \ - Simple Assembler > > > \ only forth definitions > > > require asm/basic.fs > > > also ASSEMBLER definitions > > > require asm/target.fs > > > HERE ( Begin ) > > > \ The assembler is very simple. All 16 opcodes are > > \ defined immediate so they can be inlined into colon defs. > > > \ primary opcode constant writers > > > : BA 0 , ; immediate > > : FI 1 , ; immediate > > : RI 2 , ; immediate > > : SI 3 , ; immediate > > > : DI 4 , ; immediate > > : FA 5 , ; immediate > > : RA 6 , ; immediate > > : SA 7 , ; immediate > > > : BO 8 , ; immediate > > : FO 9 , ; immediate > > : RO 10 , ; immediate > > : SO 11 , ; immediate > > > : SU 12 , ; immediate > > : FE 13 , ; immediate > > : RE 14 , ; immediate > > : SE 15 , ; immediate > > > HERE SWAP - > > CR .( Length of Assembler: ) . .( Bytes ) CR > > What instruction is a CALL? How do you specify the address? How do > you specify literal data? > > Rick $addr ,Article: 139023
Maybe it's you ;) > > Man, some people just don't get it. Regarding my real name: Helmar. What you and others not get is: "Zero Operand Cpu" is something like "Wir sind Papst!" in Germany. Why did not FORTH INC., forth.com make advertise with "The Zero-Operand Language!" all the last years? It would save a lot of time for programmers, not to care about operands. I guess they do not for good reasons. -Helmar (...censored...)Article: 139024
On Mar 18, 7:54=A0pm, Jacko <jackokr...@gmail.com> wrote: > On 18 Mar, 16:59, rickman <gnu...@gmail.com> wrote: > > > > > On Mar 18, 8:36 am, Jacko <jackokr...@gmail.com> wrote: > > > > \ FORTH Assembler for nibz > > > \ > > > \ Copyright (C) 2006,2007,2009 Free Software Foundation, Inc. > > > > \ This file is part of Gforth. > > > > \ Gforth is free software; you can redistribute it and/or > > > \ modify it under the terms of the GNU General Public License > > > \ as published by the Free Software Foundation, either version 3 > > > \ of the License, or (at your option) any later version. > > > > \ This program is distributed in the hope that it will be useful, > > > \ but WITHOUT ANY WARRANTY; without even the implied warranty of > > > \ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. =A0See the > > > \ GNU General Public License for more details. > > > > \ You should have received a copy of the GNU General Public License > > > \ along with this program. If not, seehttp://www.gnu.org/licenses/. > > > \ > > > \ Autor: =A0 =A0 =A0 =A0 =A0Simon Jackson, BEng. > > > \ > > > \ Information: > > > \ > > > \ - Simple Assembler > > > > \ only forth definitions > > > > require asm/basic.fs > > > > =A0also ASSEMBLER definitions > > > > require asm/target.fs > > > > =A0HERE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ( Begin ) > > > > \ The assembler is very simple. All 16 opcodes are > > > \ defined immediate so they can be inlined into colon defs. > > > > \ primary opcode constant writers > > > > : BA 0 , ; immediate > > > : FI 1 , ; immediate > > > : RI 2 , ; immediate > > > : SI 3 , ; immediate > > > > : DI 4 , ; immediate > > > : FA 5 , ; immediate > > > : RA 6 , ; immediate > > > : SA 7 , ; immediate > > > > : BO 8 , ; immediate > > > : FO 9 , ; immediate > > > : RO 10 , ; immediate > > > : SO 11 , ; immediate > > > > : SU 12 , ; immediate > > > : FE 13 , ; immediate > > > : RE 14 , ; immediate > > > : SE 15 , ; immediate > > > > =A0HERE =A0SWAP - > > > =A0CR .( Length of Assembler: ) . .( Bytes ) CR > > > What instruction is a CALL? =A0How do you specify the address? =A0How d= o > > you specify literal data? > > > Rick > > $addr , Jacko your comments are just getting more and more fuzzy and cryptic. is that on purpose? Antti
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