Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #48971 > unrolled thread
| Started by | foxaudioresearch@gmail.com |
|---|---|
| First post | 2016-07-08 17:44 -0700 |
| Last post | 2016-07-11 08:03 -0700 |
| Articles | 20 on this page of 67 — 18 participants |
Back to article view | Back to comp.lang.forth
Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-08 17:44 -0700
Re: Forth coding style vs "Algol et al" coding style "WJ" <w_a_x_man@yahoo.com> - 2016-07-09 04:27 +0000
Re: Forth coding style vs "Algol et al" coding style humptydumpty <ouatubi@gmail.com> - 2016-07-09 10:30 -0700
Re: Forth coding style vs "Algol et al" coding style Julian Fondren <julian.fondren@gmail.com> - 2016-07-09 21:56 -0700
Re: Forth coding style vs "Algol et al" coding style mhx@iae.nl - 2016-07-10 00:30 -0700
Re: Forth coding style vs "Algol et al" coding style mhx@iae.nl - 2016-07-10 00:34 -0700
Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-10 09:10 -0700
Re: Forth coding style vs "Algol et al" coding style endlessboomcapitalism@gmail.com - 2016-07-12 18:55 -0700
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-10 01:39 -0700
Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-10 08:50 -0700
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-10 15:00 -0700
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-10 22:53 -0400
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 01:59 -0700
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-11 09:44 -0400
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 10:51 -0700
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-11 15:26 -0400
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-12 15:18 -0700
Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-25 19:56 -0700
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-25 23:13 -0400
Re: Forth coding style vs "Algol et al" coding style jim.brakefield@ieee.org - 2016-07-26 07:34 -0700
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-26 11:23 -0400
Re: Forth coding style vs "Algol et al" coding style jim.brakefield@ieee.org - 2016-07-26 13:18 -0700
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-26 18:14 -0400
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-27 02:43 -0700
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-27 10:24 -0400
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-27 02:46 -0700
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-27 10:26 -0400
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-27 02:53 -0700
Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-27 08:32 -0700
Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-27 09:04 -0700
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-28 02:05 -0700
Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-28 06:27 -0700
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-29 03:01 -0700
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-30 02:28 -0400
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-11 13:05 -0400
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 10:47 -0700
Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-11 08:50 -0500
Re: Forth coding style vs "Algol et al" coding style Michael Barry <barrym95838@yahoo.com> - 2016-07-11 08:23 -0700
Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-11 11:48 -0500
Re: Forth coding style vs "Algol et al" coding style Cecil Bayona <cbayona@cbayona.com> - 2016-07-11 12:16 -0500
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 10:38 -0700
Re: Forth coding style vs "Algol et al" coding style Cecil Bayona <cbayona@cbayona.com> - 2016-07-11 13:32 -0500
Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-11 12:45 -0500
Re: Forth coding style vs "Algol et al" coding style Brad Eckert <hwfwguy@gmail.com> - 2016-07-11 11:49 -0700
Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-12 05:02 -0500
Re: Forth coding style vs "Algol et al" coding style Michael Barry <barrym95838@yahoo.com> - 2016-07-11 14:22 -0700
Re: Forth coding style vs "Algol et al" coding style Cecil Bayona <cbayona@cbayona.com> - 2016-07-11 16:31 -0500
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-12 15:31 -0400
Re: Forth coding style vs "Algol et al" coding style lawrencedo99@gmail.com - 2016-07-12 15:55 -0700
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-25 22:48 -0400
Re: Forth coding style vs "Algol et al" coding style lawrencedo99@gmail.com - 2016-08-10 01:54 -0700
Re: Forth coding style vs "Algol et al" coding style Howerd <howerdo@yahoo.co.uk> - 2016-07-11 11:58 -0700
Re: Forth coding style vs "Algol et al" coding style lawrencedo99@gmail.com - 2016-07-12 15:59 -0700
Re: Forth coding style vs "Algol et al" coding style Bernd Paysan <bernd.paysan@gmx.de> - 2016-07-26 00:40 +0000
Re: Forth coding style vs "Algol et al" coding style "Elizabeth D. Rather" <erather@forth.com> - 2016-07-25 21:16 -1000
Re: Forth coding style vs "Algol et al" coding style Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-07-26 03:34 -0500
Re: Forth coding style vs "Algol et al" coding style anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-07-26 16:51 +0000
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-26 13:51 -0400
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-25 22:50 -0400
Re: Forth coding style vs "Algol et al" coding style Brad Eckert <hwfwguy@gmail.com> - 2016-07-26 16:32 -0700
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-27 10:19 -0400
Re: Forth coding style vs "Algol et al" coding style "Elizabeth D. Rather" <erather@forth.com> - 2016-07-27 09:05 -1000
Re: Forth coding style vs "Algol et al" coding style lawrencedo99@gmail.com - 2016-07-12 15:51 -0700
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-14 03:34 -0700
Re: Forth coding style vs "Algol et al" coding style rickman <gnuarm@gmail.com> - 2016-07-25 22:51 -0400
Re: Forth coding style vs "Algol et al" coding style Mark Wills <markwills1970@gmail.com> - 2016-07-11 01:56 -0700
Re: Forth coding style vs "Algol et al" coding style foxaudioresearch@gmail.com - 2016-07-11 08:03 -0700
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-26 11:23 -0400 |
| Message-ID | <nn7v91$nt$2@dont-email.me> |
| In reply to | #49529 |
On 7/26/2016 10:34 AM, jim.brakefield@ieee.org wrote: > On Monday, July 25, 2016 at 10:13:41 PM UTC-5, rickman wrote: >> On 7/25/2016 10:56 PM, foxaudioresearch@gmail.com wrote: >>> On Monday, July 11, 2016 at 1:51:21 PM UTC-4, Mark Wills wrote: >>>> On Monday, 11 July 2016 14:44:51 UTC+1, rickman wrote: >>>>> On 7/11/2016 4:59 AM, Mark Wills wrote: >>>>>> On Monday, 11 July 2016 03:53:53 UTC+1, rickman wrote: >>>>>>> On 7/10/2016 6:00 PM, Mark Wills wrote: >>>>>>>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com wrote: >>>>>>>>> Sure have Mark. It's very nice. >>>>>>>>> >>>>>>>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register. >>>>>>>>> >>>>>>>>> The cycle count looks like it will be faster. >>>>>>>>> >>>>>>>>> >>>>>>>>> Boy I like that TmS9900 instruction set better than x86. >>>>>>>>> >>>>>>>>> Just needs a stack pointer or 2 in Hardware. >>>>>>>>> >>>>>>>>> B >>>>>>>> >>>>>>>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor >>>>>>>> over the years. The 68K comes a close second for me :-) >>>>>>> >>>>>>> Funny, I still have a couple of TMS99x computers around here somewhere. >>>>>>> One is a Technico 9900 single board computer that uses EPROMs. Another >>>>>>> is one I designed using a 9995 built with wire wrap. I wanted to use >>>>>>> the 9995 to control an IBM Selectric I got at a something-fest, but it >>>>>>> was too worn out to print reliably. Seems those mechanicals don't last >>>>>>> forever. Both CPU boards are sitting in my basement next to an old 8008 >>>>>>> multiple board computer. >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Rick C >>>>>> >>>>>> The 9995s and (in-particular) the 9900s are getting quite valuable now. The >>>>>> 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery, >>>>>> whereas the 9900 at least requires a 4-phase clock. Their register to memory >>>>>> architecture is beautiful. If only they had a hardware stack! (Later variants >>>>>> of the 99xx family did indeed have hardware stacks and a whole raft of >>>>>> additional instructions). >>>>> >>>>> Why would you want a hardware stack? That would be limited in size and >>>>> likely function. The 8008 predecessor to the 8080 has a small hardware >>>>> stack. >>>>> >>>>> Or do you mean a dedicated stack pointer in the chip? >>>>> >>>>> -- >>>>> >>>>> Rick C >>>> >>>> Yes, just a stack pointer, and MOV instructions to get push/pop. >>>> >>>> It's fairly simple to anyway. Suppose R0 is your stack pointer register: >>>> >>>> LI R0,$E000 - stack is at $E000 >>>> >>>> to push data: >>>> DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes) >>>> MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0 >>>> >>>> to pop: >>>> MOV *R0+,Rx - move data at address addressed by R0 to Rx, and increase R0 by two >>> >>> I always feel cramped with the single level sub-routine call linked in R11. >>> (Branch and link) >>> Although it sucks up way too many cycles on these machines, I created a macros >>> in Forth assembler that let me have what I want when I need it. >>> >>> \ PUSH & POP on both stacks >>> : PUSH, ( src -- ) SP DECT, *SP MOV, ; >>> : POP, ( dst -- ) *SP+ SWAP MOV, ; >>> >>> : RPUSH, ( src -- ) RP DECT, *RP MOV, ; >>> : RPOP, ( dst -- ) *RP+ SWAP MOV, ; >>> >>> Then I extended branch & link. >>> >>> : CALL, ( dst -- ) R11 RPUSH, ( addr) BL, R11 RPOP, ; >>> >>> And return remains the same: >>> : RT *R11 B, ; >>> >>> If only it was in hardware... >> >> These days a TMS9900 processor could be done in an FPGA and run much >> faster than the original. It could also look ahead at the instruction >> sequences you use and do them in a single instruction (even though it >> would still need to fetch it all to do the lookahead). This could >> maintain machine code level compatibility and work much faster. >> >> -- >> >> Rick C > > ]>These days a TMS9900 processor could be done in an FPGA and run much >> faster than the original. > > Check out neo430 and openmsp430 at opencores.org (in processor section). > neo430 can achieve a clock rate of 264MHz and openmsp430 116 MHz > (different implementations, so speed not directly proportional to fmax) Not sure what you mean by "speed not directly proportional to fmax". Do you mean the speed of running code does not match the clock speed? Everyone should be aware of that, but I guess many assume the same instruction set will have a fixed correspondence with the frequency. As you say, that is not universally true. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2016-07-26 13:18 -0700 |
| Message-ID | <83eb9f9c-aff2-4036-996e-2f4e370e2a0e@googlegroups.com> |
| In reply to | #49532 |
On Tuesday, July 26, 2016 at 10:23:15 AM UTC-5, rickman wrote: > On 7/26/2016 10:34 AM, jim.brakefield@ieee.org wrote: > > On Monday, July 25, 2016 at 10:13:41 PM UTC-5, rickman wrote: > >> On 7/25/2016 10:56 PM, foxaudioresearch@gmail.com wrote: > >>> On Monday, July 11, 2016 at 1:51:21 PM UTC-4, Mark Wills wrote: > >>>> On Monday, 11 July 2016 14:44:51 UTC+1, rickman wrote: > >>>>> On 7/11/2016 4:59 AM, Mark Wills wrote: > >>>>>> On Monday, 11 July 2016 03:53:53 UTC+1, rickman wrote: > >>>>>>> On 7/10/2016 6:00 PM, Mark Wills wrote: > >>>>>>>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com wrote: > >>>>>>>>> Sure have Mark. It's very nice. > >>>>>>>>> > >>>>>>>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register. > >>>>>>>>> > >>>>>>>>> The cycle count looks like it will be faster. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Boy I like that TmS9900 instruction set better than x86. > >>>>>>>>> > >>>>>>>>> Just needs a stack pointer or 2 in Hardware. > >>>>>>>>> > >>>>>>>>> B > >>>>>>>> > >>>>>>>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor > >>>>>>>> over the years. The 68K comes a close second for me :-) > >>>>>>> > >>>>>>> Funny, I still have a couple of TMS99x computers around here somewhere. > >>>>>>> One is a Technico 9900 single board computer that uses EPROMs. Another > >>>>>>> is one I designed using a 9995 built with wire wrap. I wanted to use > >>>>>>> the 9995 to control an IBM Selectric I got at a something-fest, but it > >>>>>>> was too worn out to print reliably. Seems those mechanicals don't last > >>>>>>> forever. Both CPU boards are sitting in my basement next to an old 8008 > >>>>>>> multiple board computer. > >>>>>>> > >>>>>>> -- > >>>>>>> > >>>>>>> Rick C > >>>>>> > >>>>>> The 9995s and (in-particular) the 9900s are getting quite valuable now. The > >>>>>> 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery, > >>>>>> whereas the 9900 at least requires a 4-phase clock. Their register to memory > >>>>>> architecture is beautiful. If only they had a hardware stack! (Later variants > >>>>>> of the 99xx family did indeed have hardware stacks and a whole raft of > >>>>>> additional instructions). > >>>>> > >>>>> Why would you want a hardware stack? That would be limited in size and > >>>>> likely function. The 8008 predecessor to the 8080 has a small hardware > >>>>> stack. > >>>>> > >>>>> Or do you mean a dedicated stack pointer in the chip? > >>>>> > >>>>> -- > >>>>> > >>>>> Rick C > >>>> > >>>> Yes, just a stack pointer, and MOV instructions to get push/pop. > >>>> > >>>> It's fairly simple to anyway. Suppose R0 is your stack pointer register: > >>>> > >>>> LI R0,$E000 - stack is at $E000 > >>>> > >>>> to push data: > >>>> DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes) > >>>> MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0 > >>>> > >>>> to pop: > >>>> MOV *R0+,Rx - move data at address addressed by R0 to Rx, and increase R0 by two > >>> > >>> I always feel cramped with the single level sub-routine call linked in R11. > >>> (Branch and link) > >>> Although it sucks up way too many cycles on these machines, I created a macros > >>> in Forth assembler that let me have what I want when I need it. > >>> > >>> \ PUSH & POP on both stacks > >>> : PUSH, ( src -- ) SP DECT, *SP MOV, ; > >>> : POP, ( dst -- ) *SP+ SWAP MOV, ; > >>> > >>> : RPUSH, ( src -- ) RP DECT, *RP MOV, ; > >>> : RPOP, ( dst -- ) *RP+ SWAP MOV, ; > >>> > >>> Then I extended branch & link. > >>> > >>> : CALL, ( dst -- ) R11 RPUSH, ( addr) BL, R11 RPOP, ; > >>> > >>> And return remains the same: > >>> : RT *R11 B, ; > >>> > >>> If only it was in hardware... > >> > >> These days a TMS9900 processor could be done in an FPGA and run much > >> faster than the original. It could also look ahead at the instruction > >> sequences you use and do them in a single instruction (even though it > >> would still need to fetch it all to do the lookahead). This could > >> maintain machine code level compatibility and work much faster. > >> > >> -- > >> > >> Rick C > > > > ]>These days a TMS9900 processor could be done in an FPGA and run much > >> faster than the original. > > > > Check out neo430 and openmsp430 at opencores.org (in processor section). > > neo430 can achieve a clock rate of 264MHz and openmsp430 116 MHz > > (different implementations, so speed not directly proportional to fmax) > > Not sure what you mean by "speed not directly proportional to fmax". Do > you mean the speed of running code does not match the clock speed? > Everyone should be aware of that, but I guess many assume the same > instruction set will have a fixed correspondence with the frequency. As > you say, that is not universally true. > > -- > > Rick C ]> Not sure what you mean by "speed not directly proportional to fmax" With two distinct implementations, the number of clocks per instruction varies. Indications are that the neo430 is slightly faster than the openmsp430 in the drystone sense even though its clock rate is twice as fast. Compounding the comparison is that each uses different amounts of FPGA resources.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-26 18:14 -0400 |
| Message-ID | <nn8ncl$qpf$3@dont-email.me> |
| In reply to | #49547 |
On 7/26/2016 4:18 PM, jim.brakefield@ieee.org wrote: > On Tuesday, July 26, 2016 at 10:23:15 AM UTC-5, rickman wrote: >> On 7/26/2016 10:34 AM, jim.brakefield@ieee.org wrote: >>> On Monday, July 25, 2016 at 10:13:41 PM UTC-5, rickman wrote: >>>> On 7/25/2016 10:56 PM, foxaudioresearch@gmail.com wrote: >>>>> On Monday, July 11, 2016 at 1:51:21 PM UTC-4, Mark Wills wrote: >>>>>> On Monday, 11 July 2016 14:44:51 UTC+1, rickman wrote: >>>>>>> On 7/11/2016 4:59 AM, Mark Wills wrote: >>>>>>>> On Monday, 11 July 2016 03:53:53 UTC+1, rickman wrote: >>>>>>>>> On 7/10/2016 6:00 PM, Mark Wills wrote: >>>>>>>>>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com wrote: >>>>>>>>>>> Sure have Mark. It's very nice. >>>>>>>>>>> >>>>>>>>>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register. >>>>>>>>>>> >>>>>>>>>>> The cycle count looks like it will be faster. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Boy I like that TmS9900 instruction set better than x86. >>>>>>>>>>> >>>>>>>>>>> Just needs a stack pointer or 2 in Hardware. >>>>>>>>>>> >>>>>>>>>>> B >>>>>>>>>> >>>>>>>>>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor >>>>>>>>>> over the years. The 68K comes a close second for me :-) >>>>>>>>> >>>>>>>>> Funny, I still have a couple of TMS99x computers around here somewhere. >>>>>>>>> One is a Technico 9900 single board computer that uses EPROMs. Another >>>>>>>>> is one I designed using a 9995 built with wire wrap. I wanted to use >>>>>>>>> the 9995 to control an IBM Selectric I got at a something-fest, but it >>>>>>>>> was too worn out to print reliably. Seems those mechanicals don't last >>>>>>>>> forever. Both CPU boards are sitting in my basement next to an old 8008 >>>>>>>>> multiple board computer. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Rick C >>>>>>>> >>>>>>>> The 9995s and (in-particular) the 9900s are getting quite valuable now. The >>>>>>>> 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery, >>>>>>>> whereas the 9900 at least requires a 4-phase clock. Their register to memory >>>>>>>> architecture is beautiful. If only they had a hardware stack! (Later variants >>>>>>>> of the 99xx family did indeed have hardware stacks and a whole raft of >>>>>>>> additional instructions). >>>>>>> >>>>>>> Why would you want a hardware stack? That would be limited in size and >>>>>>> likely function. The 8008 predecessor to the 8080 has a small hardware >>>>>>> stack. >>>>>>> >>>>>>> Or do you mean a dedicated stack pointer in the chip? >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Rick C >>>>>> >>>>>> Yes, just a stack pointer, and MOV instructions to get push/pop. >>>>>> >>>>>> It's fairly simple to anyway. Suppose R0 is your stack pointer register: >>>>>> >>>>>> LI R0,$E000 - stack is at $E000 >>>>>> >>>>>> to push data: >>>>>> DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes) >>>>>> MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0 >>>>>> >>>>>> to pop: >>>>>> MOV *R0+,Rx - move data at address addressed by R0 to Rx, and increase R0 by two >>>>> >>>>> I always feel cramped with the single level sub-routine call linked in R11. >>>>> (Branch and link) >>>>> Although it sucks up way too many cycles on these machines, I created a macros >>>>> in Forth assembler that let me have what I want when I need it. >>>>> >>>>> \ PUSH & POP on both stacks >>>>> : PUSH, ( src -- ) SP DECT, *SP MOV, ; >>>>> : POP, ( dst -- ) *SP+ SWAP MOV, ; >>>>> >>>>> : RPUSH, ( src -- ) RP DECT, *RP MOV, ; >>>>> : RPOP, ( dst -- ) *RP+ SWAP MOV, ; >>>>> >>>>> Then I extended branch & link. >>>>> >>>>> : CALL, ( dst -- ) R11 RPUSH, ( addr) BL, R11 RPOP, ; >>>>> >>>>> And return remains the same: >>>>> : RT *R11 B, ; >>>>> >>>>> If only it was in hardware... >>>> >>>> These days a TMS9900 processor could be done in an FPGA and run much >>>> faster than the original. It could also look ahead at the instruction >>>> sequences you use and do them in a single instruction (even though it >>>> would still need to fetch it all to do the lookahead). This could >>>> maintain machine code level compatibility and work much faster. >>>> >>>> -- >>>> >>>> Rick C >>> >>> ]>These days a TMS9900 processor could be done in an FPGA and run much >>>> faster than the original. >>> >>> Check out neo430 and openmsp430 at opencores.org (in processor section). >>> neo430 can achieve a clock rate of 264MHz and openmsp430 116 MHz >>> (different implementations, so speed not directly proportional to fmax) >> >> Not sure what you mean by "speed not directly proportional to fmax". Do >> you mean the speed of running code does not match the clock speed? >> Everyone should be aware of that, but I guess many assume the same >> instruction set will have a fixed correspondence with the frequency. As >> you say, that is not universally true. >> >> -- >> >> Rick C > > ]> Not sure what you mean by "speed not directly proportional to fmax" > > With two distinct implementations, the number of clocks per instruction varies. > Indications are that the neo430 is slightly faster than the openmsp430 in the drystone sense even though its clock rate is twice as fast. Compounding the comparison is that each uses different amounts of FPGA resources. Ok. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-07-27 02:43 -0700 |
| Message-ID | <a2b5c634-e2a9-40d3-8858-1e56f64af6b5@googlegroups.com> |
| In reply to | #49514 |
On Tuesday, 26 July 2016 04:13:41 UTC+1, rickman wrote: > On 7/25/2016 10:56 PM, foxaudioresearch@gmail.com wrote: > > On Monday, July 11, 2016 at 1:51:21 PM UTC-4, Mark Wills wrote: > >> On Monday, 11 July 2016 14:44:51 UTC+1, rickman wrote: > >>> On 7/11/2016 4:59 AM, Mark Wills wrote: > >>>> On Monday, 11 July 2016 03:53:53 UTC+1, rickman wrote: > >>>>> On 7/10/2016 6:00 PM, Mark Wills wrote: > >>>>>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com wrote: > >>>>>>> Sure have Mark. It's very nice. > >>>>>>> > >>>>>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register. > >>>>>>> > >>>>>>> The cycle count looks like it will be faster. > >>>>>>> > >>>>>>> > >>>>>>> Boy I like that TmS9900 instruction set better than x86. > >>>>>>> > >>>>>>> Just needs a stack pointer or 2 in Hardware. > >>>>>>> > >>>>>>> B > >>>>>> > >>>>>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor > >>>>>> over the years. The 68K comes a close second for me :-) > >>>>> > >>>>> Funny, I still have a couple of TMS99x computers around here somewhere. > >>>>> One is a Technico 9900 single board computer that uses EPROMs. Another > >>>>> is one I designed using a 9995 built with wire wrap. I wanted to use > >>>>> the 9995 to control an IBM Selectric I got at a something-fest, but it > >>>>> was too worn out to print reliably. Seems those mechanicals don't last > >>>>> forever. Both CPU boards are sitting in my basement next to an old 8008 > >>>>> multiple board computer. > >>>>> > >>>>> -- > >>>>> > >>>>> Rick C > >>>> > >>>> The 9995s and (in-particular) the 9900s are getting quite valuable now. The > >>>> 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery, > >>>> whereas the 9900 at least requires a 4-phase clock. Their register to memory > >>>> architecture is beautiful. If only they had a hardware stack! (Later variants > >>>> of the 99xx family did indeed have hardware stacks and a whole raft of > >>>> additional instructions). > >>> > >>> Why would you want a hardware stack? That would be limited in size and > >>> likely function. The 8008 predecessor to the 8080 has a small hardware > >>> stack. > >>> > >>> Or do you mean a dedicated stack pointer in the chip? > >>> > >>> -- > >>> > >>> Rick C > >> > >> Yes, just a stack pointer, and MOV instructions to get push/pop. > >> > >> It's fairly simple to anyway. Suppose R0 is your stack pointer register: > >> > >> LI R0,$E000 - stack is at $E000 > >> > >> to push data: > >> DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes) > >> MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0 > >> > >> to pop: > >> MOV *R0+,Rx - move data at address addressed by R0 to Rx, and increase R0 by two > > > > I always feel cramped with the single level sub-routine call linked in R11. > > (Branch and link) > > Although it sucks up way too many cycles on these machines, I created a macros > > in Forth assembler that let me have what I want when I need it. > > > > \ PUSH & POP on both stacks > > : PUSH, ( src -- ) SP DECT, *SP MOV, ; > > : POP, ( dst -- ) *SP+ SWAP MOV, ; > > > > : RPUSH, ( src -- ) RP DECT, *RP MOV, ; > > : RPOP, ( dst -- ) *RP+ SWAP MOV, ; > > > > Then I extended branch & link. > > > > : CALL, ( dst -- ) R11 RPUSH, ( addr) BL, R11 RPOP, ; > > > > And return remains the same: > > : RT *R11 B, ; > > > > If only it was in hardware... > > These days a TMS9900 processor could be done in an FPGA and run much > faster than the original. It could also look ahead at the instruction > sequences you use and do them in a single instruction (even though it > would still need to fetch it all to do the lookahead). This could > maintain machine code level compatibility and work much faster. > > -- > > Rick C It could also implement extra features such a real data and return stack. There's plenty of op-code redundancy in the various instruction types to add extra instructions. The 4 phase clock would obviously not be required, (in fact, probably no clock at all), and the 64K address could sit entirely in the FPGA, no need for an external address or data bus. WHAT ARE YOU WAITING FOR RICK? ;-)
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-27 10:24 -0400 |
| Message-ID | <nnag7q$nvs$8@dont-email.me> |
| In reply to | #49553 |
On 7/27/2016 5:43 AM, Mark Wills wrote: > On Tuesday, 26 July 2016 04:13:41 UTC+1, rickman wrote: >> On 7/25/2016 10:56 PM, foxaudioresearch@gmail.com wrote: >>> On Monday, July 11, 2016 at 1:51:21 PM UTC-4, Mark Wills wrote: >>>> On Monday, 11 July 2016 14:44:51 UTC+1, rickman wrote: >>>>> On 7/11/2016 4:59 AM, Mark Wills wrote: >>>>>> On Monday, 11 July 2016 03:53:53 UTC+1, rickman wrote: >>>>>>> On 7/10/2016 6:00 PM, Mark Wills wrote: >>>>>>>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com wrote: >>>>>>>>> Sure have Mark. It's very nice. >>>>>>>>> >>>>>>>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register. >>>>>>>>> >>>>>>>>> The cycle count looks like it will be faster. >>>>>>>>> >>>>>>>>> >>>>>>>>> Boy I like that TmS9900 instruction set better than x86. >>>>>>>>> >>>>>>>>> Just needs a stack pointer or 2 in Hardware. >>>>>>>>> >>>>>>>>> B >>>>>>>> >>>>>>>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor >>>>>>>> over the years. The 68K comes a close second for me :-) >>>>>>> >>>>>>> Funny, I still have a couple of TMS99x computers around here somewhere. >>>>>>> One is a Technico 9900 single board computer that uses EPROMs. Another >>>>>>> is one I designed using a 9995 built with wire wrap. I wanted to use >>>>>>> the 9995 to control an IBM Selectric I got at a something-fest, but it >>>>>>> was too worn out to print reliably. Seems those mechanicals don't last >>>>>>> forever. Both CPU boards are sitting in my basement next to an old 8008 >>>>>>> multiple board computer. >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Rick C >>>>>> >>>>>> The 9995s and (in-particular) the 9900s are getting quite valuable now. The >>>>>> 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery, >>>>>> whereas the 9900 at least requires a 4-phase clock. Their register to memory >>>>>> architecture is beautiful. If only they had a hardware stack! (Later variants >>>>>> of the 99xx family did indeed have hardware stacks and a whole raft of >>>>>> additional instructions). >>>>> >>>>> Why would you want a hardware stack? That would be limited in size and >>>>> likely function. The 8008 predecessor to the 8080 has a small hardware >>>>> stack. >>>>> >>>>> Or do you mean a dedicated stack pointer in the chip? >>>>> >>>>> -- >>>>> >>>>> Rick C >>>> >>>> Yes, just a stack pointer, and MOV instructions to get push/pop. >>>> >>>> It's fairly simple to anyway. Suppose R0 is your stack pointer register: >>>> >>>> LI R0,$E000 - stack is at $E000 >>>> >>>> to push data: >>>> DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes) >>>> MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0 >>>> >>>> to pop: >>>> MOV *R0+,Rx - move data at address addressed by R0 to Rx, and increase R0 by two >>> >>> I always feel cramped with the single level sub-routine call linked in R11. >>> (Branch and link) >>> Although it sucks up way too many cycles on these machines, I created a macros >>> in Forth assembler that let me have what I want when I need it. >>> >>> \ PUSH & POP on both stacks >>> : PUSH, ( src -- ) SP DECT, *SP MOV, ; >>> : POP, ( dst -- ) *SP+ SWAP MOV, ; >>> >>> : RPUSH, ( src -- ) RP DECT, *RP MOV, ; >>> : RPOP, ( dst -- ) *RP+ SWAP MOV, ; >>> >>> Then I extended branch & link. >>> >>> : CALL, ( dst -- ) R11 RPUSH, ( addr) BL, R11 RPOP, ; >>> >>> And return remains the same: >>> : RT *R11 B, ; >>> >>> If only it was in hardware... >> >> These days a TMS9900 processor could be done in an FPGA and run much >> faster than the original. It could also look ahead at the instruction >> sequences you use and do them in a single instruction (even though it >> would still need to fetch it all to do the lookahead). This could >> maintain machine code level compatibility and work much faster. >> >> -- >> >> Rick C > > It could also implement extra features such a real data and return stack. > > There's plenty of op-code redundancy in the various instruction types to > add extra instructions. The 4 phase clock would obviously not be required, > (in fact, probably no clock at all), and the 64K address could sit entirely > in the FPGA, no need for an external address or data bus. > > WHAT ARE YOU WAITING FOR RICK? ;-) No clock at all? Reminds me of the joke about the airliner pilot announcing a problem with one of the four engines so they would be arriving a half hour late. A while later he announces a second engine failed and they would be an hour late. Then he announces a third engine failed and they will be three hours late. One passenger says to the other, "If that fourth engine fails we'll be up here all day!" How do you run without a clock? I'm waiting for some financial incentive... also, I'm not a fan of CPUs with more than one clock cycle per instruction. I suppose it could be pipelined which I'm also not a fan of, but an interesting challenge. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-07-27 02:46 -0700 |
| Message-ID | <a3d3bcd6-7b25-4ea1-b22d-3e9ed6caa006@googlegroups.com> |
| In reply to | #49512 |
On Tuesday, 26 July 2016 03:56:54 UTC+1, foxaudio...@gmail.com wrote: > On Monday, July 11, 2016 at 1:51:21 PM UTC-4, Mark Wills wrote: > > On Monday, 11 July 2016 14:44:51 UTC+1, rickman wrote: > > > On 7/11/2016 4:59 AM, Mark Wills wrote: > > > > On Monday, 11 July 2016 03:53:53 UTC+1, rickman wrote: > > > >> On 7/10/2016 6:00 PM, Mark Wills wrote: > > > >>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com wrote: > > > >>>> Sure have Mark. It's very nice. > > > >>>> > > > >>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register. > > > >>>> > > > >>>> The cycle count looks like it will be faster. > > > >>>> > > > >>>> > > > >>>> Boy I like that TmS9900 instruction set better than x86. > > > >>>> > > > >>>> Just needs a stack pointer or 2 in Hardware. > > > >>>> > > > >>>> B > > > >>> > > > >>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor > > > >>> over the years. The 68K comes a close second for me :-) > > > >> > > > >> Funny, I still have a couple of TMS99x computers around here somewhere. > > > >> One is a Technico 9900 single board computer that uses EPROMs. Another > > > >> is one I designed using a 9995 built with wire wrap. I wanted to use > > > >> the 9995 to control an IBM Selectric I got at a something-fest, but it > > > >> was too worn out to print reliably. Seems those mechanicals don't last > > > >> forever. Both CPU boards are sitting in my basement next to an old 8008 > > > >> multiple board computer. > > > >> > > > >> -- > > > >> > > > >> Rick C > > > > > > > > The 9995s and (in-particular) the 9900s are getting quite valuable now. The > > > > 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery, > > > > whereas the 9900 at least requires a 4-phase clock. Their register to memory > > > > architecture is beautiful. If only they had a hardware stack! (Later variants > > > > of the 99xx family did indeed have hardware stacks and a whole raft of > > > > additional instructions). > > > > > > Why would you want a hardware stack? That would be limited in size and > > > likely function. The 8008 predecessor to the 8080 has a small hardware > > > stack. > > > > > > Or do you mean a dedicated stack pointer in the chip? > > > > > > -- > > > > > > Rick C > > > > Yes, just a stack pointer, and MOV instructions to get push/pop. > > > > It's fairly simple to anyway. Suppose R0 is your stack pointer register: > > > > LI R0,$E000 - stack is at $E000 > > > > to push data: > > DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes) > > MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0 > > > > to pop: > > MOV *R0+,Rx - move data at address addressed by R0 to Rx, and increase R0 by two > > I always feel cramped with the single level sub-routine call linked in R11. > (Branch and link) > Although it sucks up way too many cycles on these machines, I created a macros > in Forth assembler that let me have what I want when I need it. > > \ PUSH & POP on both stacks > : PUSH, ( src -- ) SP DECT, *SP MOV, ; > : POP, ( dst -- ) *SP+ SWAP MOV, ; > > : RPUSH, ( src -- ) RP DECT, *RP MOV, ; > : RPOP, ( dst -- ) *RP+ SWAP MOV, ; > > Then I extended branch & link. > > : CALL, ( dst -- ) R11 RPUSH, ( addr) BL, R11 RPOP, ; > > And return remains the same: > : RT *R11 B, ; > > If only it was in hardware... > > BF Lovely. Yes, it's the ONLY feature that I miss on the 9900. I have become so at-ease with 9900 that I can generally write pages of 9900 assembler and it will work first time. Not because I'm uber-9900er, but because it's a very simple, logical, orthogonal instruction set with plenty (16) of registers. The SOC and SZC instructions are a little strange (no OR instruction) but they're actually really neat.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-27 10:26 -0400 |
| Message-ID | <nnaga3$nvs$9@dont-email.me> |
| In reply to | #49554 |
On 7/27/2016 5:46 AM, Mark Wills wrote: > On Tuesday, 26 July 2016 03:56:54 UTC+1, foxaudio...@gmail.com wrote: >> On Monday, July 11, 2016 at 1:51:21 PM UTC-4, Mark Wills wrote: >>> On Monday, 11 July 2016 14:44:51 UTC+1, rickman wrote: >>>> On 7/11/2016 4:59 AM, Mark Wills wrote: >>>>> On Monday, 11 July 2016 03:53:53 UTC+1, rickman wrote: >>>>>> On 7/10/2016 6:00 PM, Mark Wills wrote: >>>>>>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com wrote: >>>>>>>> Sure have Mark. It's very nice. >>>>>>>> >>>>>>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register. >>>>>>>> >>>>>>>> The cycle count looks like it will be faster. >>>>>>>> >>>>>>>> >>>>>>>> Boy I like that TmS9900 instruction set better than x86. >>>>>>>> >>>>>>>> Just needs a stack pointer or 2 in Hardware. >>>>>>>> >>>>>>>> B >>>>>>> >>>>>>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor >>>>>>> over the years. The 68K comes a close second for me :-) >>>>>> >>>>>> Funny, I still have a couple of TMS99x computers around here somewhere. >>>>>> One is a Technico 9900 single board computer that uses EPROMs. Another >>>>>> is one I designed using a 9995 built with wire wrap. I wanted to use >>>>>> the 9995 to control an IBM Selectric I got at a something-fest, but it >>>>>> was too worn out to print reliably. Seems those mechanicals don't last >>>>>> forever. Both CPU boards are sitting in my basement next to an old 8008 >>>>>> multiple board computer. >>>>>> >>>>>> -- >>>>>> >>>>>> Rick C >>>>> >>>>> The 9995s and (in-particular) the 9900s are getting quite valuable now. The >>>>> 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery, >>>>> whereas the 9900 at least requires a 4-phase clock. Their register to memory >>>>> architecture is beautiful. If only they had a hardware stack! (Later variants >>>>> of the 99xx family did indeed have hardware stacks and a whole raft of >>>>> additional instructions). >>>> >>>> Why would you want a hardware stack? That would be limited in size and >>>> likely function. The 8008 predecessor to the 8080 has a small hardware >>>> stack. >>>> >>>> Or do you mean a dedicated stack pointer in the chip? >>>> >>>> -- >>>> >>>> Rick C >>> >>> Yes, just a stack pointer, and MOV instructions to get push/pop. >>> >>> It's fairly simple to anyway. Suppose R0 is your stack pointer register: >>> >>> LI R0,$E000 - stack is at $E000 >>> >>> to push data: >>> DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes) >>> MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0 >>> >>> to pop: >>> MOV *R0+,Rx - move data at address addressed by R0 to Rx, and increase R0 by two >> >> I always feel cramped with the single level sub-routine call linked in R11. >> (Branch and link) >> Although it sucks up way too many cycles on these machines, I created a macros >> in Forth assembler that let me have what I want when I need it. >> >> \ PUSH & POP on both stacks >> : PUSH, ( src -- ) SP DECT, *SP MOV, ; >> : POP, ( dst -- ) *SP+ SWAP MOV, ; >> >> : RPUSH, ( src -- ) RP DECT, *RP MOV, ; >> : RPOP, ( dst -- ) *RP+ SWAP MOV, ; >> >> Then I extended branch & link. >> >> : CALL, ( dst -- ) R11 RPUSH, ( addr) BL, R11 RPOP, ; >> >> And return remains the same: >> : RT *R11 B, ; >> >> If only it was in hardware... >> >> BF > > Lovely. Yes, it's the ONLY feature that I miss on the 9900. I have become > so at-ease with 9900 that I can generally write pages of 9900 assembler > and it will work first time. Not because I'm uber-9900er, but because it's > a very simple, logical, orthogonal instruction set with plenty (16) of > registers. > > The SOC and SZC instructions are a little strange (no OR instruction) > but they're actually really neat. Think of setting and clearing bits using bitmasks rather than logical operations. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-07-27 02:53 -0700 |
| Message-ID | <41ef68c6-0b6f-4e26-b1f5-6f634714fc84@googlegroups.com> |
| In reply to | #49512 |
On Tuesday, 26 July 2016 03:56:54 UTC+1, foxaudio...@gmail.com wrote: > On Monday, July 11, 2016 at 1:51:21 PM UTC-4, Mark Wills wrote: > > On Monday, 11 July 2016 14:44:51 UTC+1, rickman wrote: > > > On 7/11/2016 4:59 AM, Mark Wills wrote: > > > > On Monday, 11 July 2016 03:53:53 UTC+1, rickman wrote: > > > >> On 7/10/2016 6:00 PM, Mark Wills wrote: > > > >>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com wrote: > > > >>>> Sure have Mark. It's very nice. > > > >>>> > > > >>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register. > > > >>>> > > > >>>> The cycle count looks like it will be faster. > > > >>>> > > > >>>> > > > >>>> Boy I like that TmS9900 instruction set better than x86. > > > >>>> > > > >>>> Just needs a stack pointer or 2 in Hardware. > > > >>>> > > > >>>> B > > > >>> > > > >>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor > > > >>> over the years. The 68K comes a close second for me :-) > > > >> > > > >> Funny, I still have a couple of TMS99x computers around here somewhere. > > > >> One is a Technico 9900 single board computer that uses EPROMs. Another > > > >> is one I designed using a 9995 built with wire wrap. I wanted to use > > > >> the 9995 to control an IBM Selectric I got at a something-fest, but it > > > >> was too worn out to print reliably. Seems those mechanicals don't last > > > >> forever. Both CPU boards are sitting in my basement next to an old 8008 > > > >> multiple board computer. > > > >> > > > >> -- > > > >> > > > >> Rick C > > > > > > > > The 9995s and (in-particular) the 9900s are getting quite valuable now. The > > > > 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery, > > > > whereas the 9900 at least requires a 4-phase clock. Their register to memory > > > > architecture is beautiful. If only they had a hardware stack! (Later variants > > > > of the 99xx family did indeed have hardware stacks and a whole raft of > > > > additional instructions). > > > > > > Why would you want a hardware stack? That would be limited in size and > > > likely function. The 8008 predecessor to the 8080 has a small hardware > > > stack. > > > > > > Or do you mean a dedicated stack pointer in the chip? > > > > > > -- > > > > > > Rick C > > > > Yes, just a stack pointer, and MOV instructions to get push/pop. > > > > It's fairly simple to anyway. Suppose R0 is your stack pointer register: > > > > LI R0,$E000 - stack is at $E000 > > > > to push data: > > DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes) > > MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0 > > > > to pop: > > MOV *R0+,Rx - move data at address addressed by R0 to Rx, and increase R0 by two > > I always feel cramped with the single level sub-routine call linked in R11. > (Branch and link) > Although it sucks up way too many cycles on these machines, I created a macros > in Forth assembler that let me have what I want when I need it. > > \ PUSH & POP on both stacks > : PUSH, ( src -- ) SP DECT, *SP MOV, ; > : POP, ( dst -- ) *SP+ SWAP MOV, ; > > : RPUSH, ( src -- ) RP DECT, *RP MOV, ; > : RPOP, ( dst -- ) *RP+ SWAP MOV, ; > > Then I extended branch & link. > > : CALL, ( dst -- ) R11 RPUSH, ( addr) BL, R11 RPOP, ; > > And return remains the same: > : RT *R11 B, ; > > If only it was in hardware... > > BF I'm sure you know, but you could use the BLWP instruction (which was TI's replacement for the stack). Using that approach, each sub-routine will have its own workspace (how cool is that?), however you pay 32 bytes for workspace for each subroutine. That may or may not be acceptable; if you know what the deepest level of nesting is in your app then you can plan for it.
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2016-07-27 08:32 -0700 |
| Message-ID | <0ef956b5-b032-4ae7-a12c-aa6679d816dc@googlegroups.com> |
| In reply to | #49556 |
On Wednesday, July 27, 2016 at 5:53:16 AM UTC-4, Mark Wills wrote: > On Tuesday, 26 July 2016 03:56:54 UTC+1, foxaudio...@gmail.com wrote: > > On Monday, July 11, 2016 at 1:51:21 PM UTC-4, Mark Wills wrote: > > > On Monday, 11 July 2016 14:44:51 UTC+1, rickman wrote: > > > > On 7/11/2016 4:59 AM, Mark Wills wrote: > > > > > On Monday, 11 July 2016 03:53:53 UTC+1, rickman wrote: > > > > >> On 7/10/2016 6:00 PM, Mark Wills wrote: > > > > >>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com wrote: > > > > >>>> Sure have Mark. It's very nice. > > > > >>>> > > > > >>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register. > > > > >>>> > > > > >>>> The cycle count looks like it will be faster. > > > > >>>> > > > > >>>> > > > > >>>> Boy I like that TmS9900 instruction set better than x86. > > > > >>>> > > > > >>>> Just needs a stack pointer or 2 in Hardware. > > > > >>>> > > > > >>>> B > > > > >>> > > > > >>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor > > > > >>> over the years. The 68K comes a close second for me :-) > > > > >> > > > > >> Funny, I still have a couple of TMS99x computers around here somewhere. > > > > >> One is a Technico 9900 single board computer that uses EPROMs. Another > > > > >> is one I designed using a 9995 built with wire wrap. I wanted to use > > > > >> the 9995 to control an IBM Selectric I got at a something-fest, but it > > > > >> was too worn out to print reliably. Seems those mechanicals don't last > > > > >> forever. Both CPU boards are sitting in my basement next to an old 8008 > > > > >> multiple board computer. > > > > >> > > > > >> -- > > > > >> > > > > >> Rick C > > > > > > > > > > The 9995s and (in-particular) the 9900s are getting quite valuable now. The > > > > > 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery, > > > > > whereas the 9900 at least requires a 4-phase clock. Their register to memory > > > > > architecture is beautiful. If only they had a hardware stack! (Later variants > > > > > of the 99xx family did indeed have hardware stacks and a whole raft of > > > > > additional instructions). > > > > > > > > Why would you want a hardware stack? That would be limited in size and > > > > likely function. The 8008 predecessor to the 8080 has a small hardware > > > > stack. > > > > > > > > Or do you mean a dedicated stack pointer in the chip? > > > > > > > > -- > > > > > > > > Rick C > > > > > > Yes, just a stack pointer, and MOV instructions to get push/pop. > > > > > > It's fairly simple to anyway. Suppose R0 is your stack pointer register: > > > > > > LI R0,$E000 - stack is at $E000 > > > > > > to push data: > > > DECT R0 - decrement stack pointer by two (16 bit word i.e. two bytes) > > > MOV Rx,*R0 - move some register (Rx) to the memory addressed by R0 > > > > > > to pop: > > > MOV *R0+,Rx - move data at address addressed by R0 to Rx, and increase R0 by two > > > > I always feel cramped with the single level sub-routine call linked in R11. > > (Branch and link) > > Although it sucks up way too many cycles on these machines, I created a macros > > in Forth assembler that let me have what I want when I need it. > > > > \ PUSH & POP on both stacks > > : PUSH, ( src -- ) SP DECT, *SP MOV, ; > > : POP, ( dst -- ) *SP+ SWAP MOV, ; > > > > : RPUSH, ( src -- ) RP DECT, *RP MOV, ; > > : RPOP, ( dst -- ) *RP+ SWAP MOV, ; > > > > Then I extended branch & link. > > > > : CALL, ( dst -- ) R11 RPUSH, ( addr) BL, R11 RPOP, ; > > > > And return remains the same: > > : RT *R11 B, ; > > > > If only it was in hardware... > > > > BF > > I'm sure you know, but you could use the BLWP instruction (which was TI's > replacement for the stack). Using that approach, each sub-routine will > have its own workspace (how cool is that?), however you pay 32 bytes for > workspace for each subroutine. That may or may not be acceptable; if you know > what the deepest level of nesting is in your app then you can plan for it. Oh ya I know about it. It seems needlessly complicated for most sub-routine calls to me. It requires that you not only make space for new registers but also create a 4 byte structure with the workspace and address to "BLWP" to. And it is only 1 level deep as well. And to make it nestable would require saving 3 registers or doing one of those overlapping workspace things and remembering all the register translations. (I'm not smart enough for that) Seems much more complicated than pushing a register and branching to routine But... I have got some rough designs on using RTWP as the task switcher for a Forth cooperative multi-tasker. That's a cool use for it. Jumping from register set to register set in 1 instruction! I like that. BF
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2016-07-27 09:04 -0700 |
| Message-ID | <f26d1d09-20aa-4f82-b126-db3e4e73179c@googlegroups.com> |
| In reply to | #49568 |
>
> But... I have got some rough designs on using RTWP as the task switcher for a
> Forth cooperative multi-tasker. That's a cool use for it. Jumping from
> register set to register set in 1 instruction! I like that.
>
>
> BF
Here is the UNTESTED code idea. It requires Initializing the workspace
of all the tasks to become a circular queue of workspaces.
Then just bounce through them with RTWP. Makes a pretty small task
switcher.
CODE YIELD
BEGIN
RTWP, \ RETURN to previous workspace
TASKFLAG (UP) R0 MOV, \ read user var. taskflag
NE UNTIL, \ loop until true
*IP+ W MOV, \ ITC next coded inline
*W R1 MOV,
*R1 B,
END-CODE
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-07-28 02:05 -0700 |
| Message-ID | <748d791d-53de-401e-bc20-9c2f3b5af964@googlegroups.com> |
| In reply to | #49569 |
On Wednesday, 27 July 2016 17:04:19 UTC+1, foxaudio...@gmail.com wrote: > > > > But... I have got some rough designs on using RTWP as the task switcher for a > > Forth cooperative multi-tasker. That's a cool use for it. Jumping from > > register set to register set in 1 instruction! I like that. > > > > > > BF > > Here is the UNTESTED code idea. It requires Initializing the workspace > of all the tasks to become a circular queue of workspaces. > Then just bounce through them with RTWP. Makes a pretty small task > switcher. > > CODE YIELD > BEGIN > RTWP, \ RETURN to previous workspace > TASKFLAG (UP) R0 MOV, \ read user var. taskflag > NE UNTIL, \ loop until true > *IP+ W MOV, \ ITC next coded inline > *W R1 MOV, > *R1 B, > END-CODE That's a great idea. I can't see why it wouldn't work. Are you going to have pre-emptive task switching (off an interrupt) or cooperative via PAUSE?
[toc] | [prev] | [next] | [standalone]
| From | foxaudioresearch@gmail.com |
|---|---|
| Date | 2016-07-28 06:27 -0700 |
| Message-ID | <3b8adadb-c333-4502-9761-225ef3c6a318@googlegroups.com> |
| In reply to | #49604 |
On Thursday, July 28, 2016 at 5:05:43 AM UTC-4, Mark Wills wrote: > On Wednesday, 27 July 2016 17:04:19 UTC+1, foxaudio...@gmail.com wrote: > > > > > > But... I have got some rough designs on using RTWP as the task switcher for a > > > Forth cooperative multi-tasker. That's a cool use for it. Jumping from > > > register set to register set in 1 instruction! I like that. > > > > > > > > > BF > > > > Here is the UNTESTED code idea. It requires Initializing the workspace > > of all the tasks to become a circular queue of workspaces. > > Then just bounce through them with RTWP. Makes a pretty small task > > switcher. > > > > CODE YIELD > > BEGIN > > RTWP, \ RETURN to previous workspace > > TASKFLAG (UP) R0 MOV, \ read user var. taskflag > > NE UNTIL, \ loop until true > > *IP+ W MOV, \ ITC next coded inline > > *W R1 MOV, > > *R1 B, > > END-CODE > > That's a great idea. I can't see why it wouldn't work. Are you going to > have pre-emptive task switching (off an interrupt) or cooperative via PAUSE? I have never really needed pre-emeptive task switching. I put the most important thing on an interrupt to catch data and then Forth PAUSE for everything else. The word YIELD in the code example is another one of HsForth's word name choices that were not "conventional". So in fact that would be PAUSE. But it would be simple to hook it to the TI-99 interrupt, but with a few tasks running it would probably mess up some of the Graphic stuff wouldn't it? (coincidence timing?) BF
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-07-29 03:01 -0700 |
| Message-ID | <4d876576-8da8-42bc-a55f-74f37bf94993@googlegroups.com> |
| In reply to | #49611 |
On Thursday, 28 July 2016 14:27:52 UTC+1, foxaudio...@gmail.com wrote: > On Thursday, July 28, 2016 at 5:05:43 AM UTC-4, Mark Wills wrote: > > On Wednesday, 27 July 2016 17:04:19 UTC+1, foxaudio...@gmail.com wrote: > > > > > > > > But... I have got some rough designs on using RTWP as the task switcher for a > > > > Forth cooperative multi-tasker. That's a cool use for it. Jumping from > > > > register set to register set in 1 instruction! I like that. > > > > > > > > > > > > BF > > > > > > Here is the UNTESTED code idea. It requires Initializing the workspace > > > of all the tasks to become a circular queue of workspaces. > > > Then just bounce through them with RTWP. Makes a pretty small task > > > switcher. > > > > > > CODE YIELD > > > BEGIN > > > RTWP, \ RETURN to previous workspace > > > TASKFLAG (UP) R0 MOV, \ read user var. taskflag > > > NE UNTIL, \ loop until true > > > *IP+ W MOV, \ ITC next coded inline > > > *W R1 MOV, > > > *R1 B, > > > END-CODE > > > > That's a great idea. I can't see why it wouldn't work. Are you going to > > have pre-emptive task switching (off an interrupt) or cooperative via PAUSE? > > I have never really needed pre-emeptive task switching. I put the most > important thing on an interrupt to catch data and then Forth PAUSE for > everything else. > > The word YIELD in the code example is another one of HsForth's word name > choices that were not "conventional". So in fact that would be PAUSE. > > But it would be simple to hook it to the TI-99 interrupt, but with a few tasks > running it would probably mess up some of the Graphic stuff wouldn't it? (coincidence timing?) > > BF Interrupts on the TI-99/4A are tricky. There is only interrupt exposed at the hardware level. Interrupt level 2 (LIMI 2). The interrupt vector and the interrupt handler are both in ROM, so you can't change where the 9900 jumps to on an interrupt. The ISR in ROM does some house keeping: It spends a lot of time determining *where* the interrupt originated: Cassette interface, video chip, disk controller etc (why they didn't use the different interrupt lines is beyond me. Cost saving, I suppose. The 9900 has 16 levels of interrupts). Then it checks memory location 0x834C and if not zero, it jumps to the address in 0x834C. When it does so, the workspace register is loaded with 0x83E0. Note that 0x83E0 is 16-bit wide (0 wait-state) RAM in the console, part of the 256-bytes of scratch pad ram that is fitted. You can use all the registers, except for R13, R14, and R15 (these maintain the context switch info to restore CPU context when you return from the interrupt instruction). You return from the ISR with a RTWP instruction. I can't remember if the console ISR does a LIMI 0 on entry into the interrupt routine (to disable further interrupts while servicing this one). It might be a good idea to put a LIMI 0 instruction at the top of your ISR, and a LIMI 2 (to re-enable) just before your RTWP instruction. If needs be I can single step the ROM and see what it does. Give me a shout if/when you decide to use interrupts. My Forth system uses them to stream speech data to the speech synthesizer while your Forth program continues to run.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-30 02:28 -0400 |
| Message-ID | <nnhhev$s42$1@dont-email.me> |
| In reply to | #49644 |
On 7/29/2016 6:01 AM, Mark Wills wrote: > On Thursday, 28 July 2016 14:27:52 UTC+1, foxaudio...@gmail.com wrote: >> On Thursday, July 28, 2016 at 5:05:43 AM UTC-4, Mark Wills wrote: >>> On Wednesday, 27 July 2016 17:04:19 UTC+1, foxaudio...@gmail.com wrote: >>>>> >>>>> But... I have got some rough designs on using RTWP as the task switcher for a >>>>> Forth cooperative multi-tasker. That's a cool use for it. Jumping from >>>>> register set to register set in 1 instruction! I like that. >>>>> >>>>> >>>>> BF >>>> >>>> Here is the UNTESTED code idea. It requires Initializing the workspace >>>> of all the tasks to become a circular queue of workspaces. >>>> Then just bounce through them with RTWP. Makes a pretty small task >>>> switcher. >>>> >>>> CODE YIELD >>>> BEGIN >>>> RTWP, \ RETURN to previous workspace >>>> TASKFLAG (UP) R0 MOV, \ read user var. taskflag >>>> NE UNTIL, \ loop until true >>>> *IP+ W MOV, \ ITC next coded inline >>>> *W R1 MOV, >>>> *R1 B, >>>> END-CODE >>> >>> That's a great idea. I can't see why it wouldn't work. Are you going to >>> have pre-emptive task switching (off an interrupt) or cooperative via PAUSE? >> >> I have never really needed pre-emeptive task switching. I put the most >> important thing on an interrupt to catch data and then Forth PAUSE for >> everything else. >> >> The word YIELD in the code example is another one of HsForth's word name >> choices that were not "conventional". So in fact that would be PAUSE. >> >> But it would be simple to hook it to the TI-99 interrupt, but with a few tasks >> running it would probably mess up some of the Graphic stuff wouldn't it? (coincidence timing?) >> >> BF > > Interrupts on the TI-99/4A are tricky. There is only interrupt exposed > at the hardware level. Interrupt level 2 (LIMI 2). The interrupt vector > and the interrupt handler are both in ROM, so you can't change where the > 9900 jumps to on an interrupt. The ISR in ROM does some house keeping: > It spends a lot of time determining *where* the interrupt originated: > Cassette interface, video chip, disk controller etc (why they didn't > use the different interrupt lines is beyond me. Cost saving, I suppose. > The 9900 has 16 levels of interrupts). Then it checks memory location > 0x834C and if not zero, it jumps to the address in 0x834C. When it does > so, the workspace register is loaded with 0x83E0. I believe this may be because of the "train" method of module extension. I don't think they had the connector space for 16 interrupts on the connector. So everyone had to share a single interrupt. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-07-11 13:05 -0400 |
| Message-ID | <nm0jjv$83e$1@dont-email.me> |
| In reply to | #49034 |
On 7/11/2016 4:59 AM, Mark Wills wrote: > On Monday, 11 July 2016 03:53:53 UTC+1, rickman wrote: >> On 7/10/2016 6:00 PM, Mark Wills wrote: >>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com wrote: >>>> Sure have Mark. It's very nice. >>>> >>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register. >>>> >>>> The cycle count looks like it will be faster. >>>> >>>> >>>> Boy I like that TmS9900 instruction set better than x86. >>>> >>>> Just needs a stack pointer or 2 in Hardware. >>>> >>>> B >>> >>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor >>> over the years. The 68K comes a close second for me :-) >> >> Funny, I still have a couple of TMS99x computers around here somewhere. >> One is a Technico 9900 single board computer that uses EPROMs. Another >> is one I designed using a 9995 built with wire wrap. I wanted to use >> the 9995 to control an IBM Selectric I got at a something-fest, but it >> was too worn out to print reliably. Seems those mechanicals don't last >> forever. Both CPU boards are sitting in my basement next to an old 8008 >> multiple board computer. >> >> -- >> >> Rick C > > The 9995s and (in-particular) the 9900s are getting quite valuable now. The > 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery, > whereas the 9900 at least requires a 4-phase clock. Their register to memory > architecture is beautiful. If only they had a hardware stack! (Later variants > of the 99xx family did indeed have hardware stacks and a whole raft of > additional instructions). BTW, I don't know if it is widely known that the TMS9900 was a single chip version of the TI-990 minicomputer. This was the reason why the 9900 used a serial CRU interface. That was not an uncommon interface in minicomputers as they often interfaced to TTY and similar devices where speed was of no consequence. From what I read on Wikipedia, the TMS9900 was used for a couple of versions of the TI-990 minicomputer which makes sense, it would be faster than TTL logic. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Mark Wills <markwills1970@gmail.com> |
|---|---|
| Date | 2016-07-11 10:47 -0700 |
| Message-ID | <29b00d64-840b-442a-8706-e8734276cfcf@googlegroups.com> |
| In reply to | #49046 |
On Monday, 11 July 2016 18:05:05 UTC+1, rickman wrote: > On 7/11/2016 4:59 AM, Mark Wills wrote: > > On Monday, 11 July 2016 03:53:53 UTC+1, rickman wrote: > >> On 7/10/2016 6:00 PM, Mark Wills wrote: > >>> On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com wrote: > >>>> Sure have Mark. It's very nice. > >>>> > >>>> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register. > >>>> > >>>> The cycle count looks like it will be faster. > >>>> > >>>> > >>>> Boy I like that TmS9900 instruction set better than x86. > >>>> > >>>> Just needs a stack pointer or 2 in Hardware. > >>>> > >>>> B > >>> > >>> Yes, the TMS9900 instruction set is by the nicest I've used on any processor > >>> over the years. The 68K comes a close second for me :-) > >> > >> Funny, I still have a couple of TMS99x computers around here somewhere. > >> One is a Technico 9900 single board computer that uses EPROMs. Another > >> is one I designed using a 9995 built with wire wrap. I wanted to use > >> the 9995 to control an IBM Selectric I got at a something-fest, but it > >> was too worn out to print reliably. Seems those mechanicals don't last > >> forever. Both CPU boards are sitting in my basement next to an old 8008 > >> multiple board computer. > >> > >> -- > >> > >> Rick C > > > > The 9995s and (in-particular) the 9900s are getting quite valuable now. The > > 9995 is a much simpler chip to work with. IIRC it needs no supporting chippery, > > whereas the 9900 at least requires a 4-phase clock. Their register to memory > > architecture is beautiful. If only they had a hardware stack! (Later variants > > of the 99xx family did indeed have hardware stacks and a whole raft of > > additional instructions). > > BTW, I don't know if it is widely known that the TMS9900 was a single > chip version of the TI-990 minicomputer. This was the reason why the > 9900 used a serial CRU interface. That was not an uncommon interface in > minicomputers as they often interfaced to TTY and similar devices where > speed was of no consequence. > > From what I read on Wikipedia, the TMS9900 was used for a couple of > versions of the TI-990 minicomputer which makes sense, it would be > faster than TTL logic. > > -- > > Rick C Yes, the 9900 in the mini's reduced the board count, power consumption, and running temperature (increasing reliability) considerably, while making it faster. No down sides!
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-11 08:50 -0500 |
| Message-ID | <gaydnaCaveOqOR7KnZ2dnUU7-amdnZ2d@supernews.com> |
| In reply to | #49023 |
Mark Wills <markwills1970@gmail.com> wrote: > On Sunday, 10 July 2016 16:50:08 UTC+1, foxaudio...@gmail.com wrote: >> Sure have Mark. It's very nice. >> >> I am porting my cross compiler and my variation of camel Forth to Ti99. I always wanted TiForth to hold Tos is a register. >> >> The cycle count looks like it will be faster. >> >> >> Boy I like that TmS9900 instruction set better than x86. >> >> Just needs a stack pointer or 2 in Hardware. > > Yes, the TMS9900 instruction set is by the nicest I've used on any > processor over the years. The 68K comes a close second for me :-) I'll passon the 68k, but the 9900 was nice enough. Mind you, if we're going to look at an elegant 1970s minicomputer architecture, I'm pretty sure that the PDP-11 would win! Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Michael Barry <barrym95838@yahoo.com> |
|---|---|
| Date | 2016-07-11 08:23 -0700 |
| Message-ID | <801766f5-2bdc-478c-ae9c-7b25d208c85c@googlegroups.com> |
| In reply to | #49041 |
On Monday, July 11, 2016 at 6:50:54 AM UTC-7, Andrew Haley wrote: > ... Mind you, if we're > going to look at an elegant 1970s minicomputer architecture, I'm > pretty sure that the PDP-11 would win! > > Andrew. I bought a book about 35 years ago that sampled several different 16-bit microprocessors, giving a large chapter to each one and providing architecture info and assembly code examples. I think that it covered the 8086, 68000, 16000 (later renamed to 32000), 9900, and pdp-11. I was reading the chapter on the pdp-11, and had reached the detailed description of the addressing modes. My friend was sitting nearby, and suddenly asked if I was crying. I actually was, a little bit, proving beyond a shadow of a doubt that I was a true nerd. Mike B.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-07-11 11:48 -0500 |
| Message-ID | <YL-dna0VsKtXUB7KnZ2dnUU7-QHNnZ2d@supernews.com> |
| In reply to | #49043 |
Michael Barry <barrym95838@yahoo.com> wrote: > I bought a book about 35 years ago that sampled several different 16-bit > microprocessors, giving a large chapter to each one and providing > architecture info and assembly code examples. I think that it covered > the 8086, 68000, 16000 (later renamed to 32000), 9900, and pdp-11. Interesting. I was thinking it must have been the Osborne 16-bit book, but that didn't cover the PDP-11. > I was reading the chapter on the pdp-11, and had reached the detailed > description of the addressing modes. My friend was sitting nearby, and > suddenly asked if I was crying. I actually was, a little bit, proving > beyond a shadow of a doubt that I was a true nerd. Yep. :-) Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Cecil Bayona <cbayona@cbayona.com> |
|---|---|
| Date | 2016-07-11 12:16 -0500 |
| Message-ID | <nm0k90$ak1$1@dont-email.me> |
| In reply to | #49045 |
On 7/11/2016 11:48 AM, Andrew Haley wrote: > Michael Barry <barrym95838@yahoo.com> wrote: > >> I bought a book about 35 years ago that sampled several different 16-bit >> microprocessors, giving a large chapter to each one and providing >> architecture info and assembly code examples. I think that it covered >> the 8086, 68000, 16000 (later renamed to 32000), 9900, and pdp-11. > > Interesting. I was thinking it must have been the Osborne 16-bit > book, but that didn't cover the PDP-11. > >> I was reading the chapter on the pdp-11, and had reached the detailed >> description of the addressing modes. My friend was sitting nearby, and >> suddenly asked if I was crying. I actually was, a little bit, proving >> beyond a shadow of a doubt that I was a true nerd. > > Yep. :-) > > Andrew. > I been playing with FPGAs to create, Forth processors, on my list of items to create once I am more familiar with the VHDL software is to create a PDP11 from scratch, the reason it's beautiful instruction set. Funny thing is that with the FPGA one can create a PDP11 that is way faster than the original models. The TI 99XX family, and Nova mini will follow shortly after the PDP11 is working. These processors have a very nice architecture, but I would build the TI99xx without some of the silly limitations put on it with the TI 9900 personal computers such as having 8 bit limited memory, and of course a much faster CPU clock. -- Cecil - k5nwa
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web