problem while receiving negative integer in microblaze
in [FPGA]
|
Prev: Development boards for CPU development ?
Next: floating point operation in interrupt handler on ML403
From: rickman on 20 Oct 2009 15:30 On Oct 20, 3:21 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > rickman <gnu...(a)gmail.com> wrote: > > (snip) > > > Why would I care what the numeric name of the bits for a given byte > > are? I much prefer to be able to determine the weights of each bit > > without messy arithmetic. > > The part that would really confuse me is if the address bus were > > numbered with 0 as the msb. Do the big endian processors do that as > > well? Is the uBlaze really done this way? > > IBM consistently numbered the MSB 0 on S/360, S/370, XA/370, > ESA/370, ESA/390, and z/Architecture. > > Note that z/ is the 64 bit extension, where all general registers > and addresses are now 64 bits. The 32 bit instructions consistently > operate on bits 32 to 63 of general registers, leaving 0 to 31 > unchanged. > > Even more, z/ can operate on code using 64, 31, or 24 bit addressing > as appropriate, and instructions change as the addressing mode changes. > > It is nice and consistent, and not so hard to get used to. > > -- glen How are the bits in the address bus numbered? I would find it extremely confusing to deal with an address where the lsb is numbered N where N varies depending on the size of the address range. Rick
From: glen herrmannsfeldt on 20 Oct 2009 16:09 rickman <gnuarm(a)gmail.com> wrote: > On Oct 20, 3:21?pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: (snip) >> IBM consistently numbered the MSB 0 on S/360, S/370, XA/370, >> ESA/370, ESA/390, and z/Architecture. (snip) >> Even more, z/ can operate on code using 64, 31, or 24 bit addressing >> as appropriate, and instructions change as the addressing mode changes. > How are the bits in the address bus numbered? I would find it > extremely confusing to deal with an address where the lsb is numbered > N where N varies depending on the size of the address range. If by 'address bus' you mean the physical hardware, that is a separate question from the architecture. Otherwise, the numbering changed in z/, but is internally consistent. For S/360, 24 bit addresses are in bits 8 to 31 of general registers, for example, and the address as stored in the PSW is bits 40 to 63. z/ extended to 64 bits, so 24 bit addresses are in bits 40 to 63, 31 bit in 33 to 63, and 64 bit addresses in bits 0 to 63. That only comes up in reading the descriptions of the instructions. In actual coding, (software) one can write a loop in whichever way one wants. The hardware will execute it independent of the thought process of the programmer. It never confused me. -- glen
From: David Brown on 21 Oct 2009 07:16 glen herrmannsfeldt wrote: > rickman <gnuarm(a)gmail.com> wrote: >> On Oct 20, 3:21?pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > (snip) > >>> IBM consistently numbered the MSB 0 on S/360, S/370, XA/370, >>> ESA/370, ESA/390, and z/Architecture. > > (snip) >>> Even more, z/ can operate on code using 64, 31, or 24 bit addressing >>> as appropriate, and instructions change as the addressing mode changes. > >> How are the bits in the address bus numbered? I would find it >> extremely confusing to deal with an address where the lsb is numbered >> N where N varies depending on the size of the address range. > > If by 'address bus' you mean the physical hardware, that is a separate > question from the architecture. > > Otherwise, the numbering changed in z/, but is internally consistent. > > For S/360, 24 bit addresses are in bits 8 to 31 of general registers, > for example, and the address as stored in the PSW is bits 40 to 63. > > z/ extended to 64 bits, so 24 bit addresses are in bits 40 to 63, > 31 bit in 33 to 63, and 64 bit addresses in bits 0 to 63. > > That only comes up in reading the descriptions of the instructions. > This is "nice and consistent" ?? The bit numbering for the same address varies according to the size of the register, and the significance of a bit of a given number varies according to the register, the bit width, and the machine variant. I'll agree that much of this is hidden from the programmer, and that you can get used to it, but it's still inconsistent and it's still messy. I've dealt with this in the context of PPC microcontrollers - it is a big pain in the neck, and it's very easy to get wrong. Virtually everything else in the electronics world numbers bits consistently from 0 for the LSB - the PPC sticks out like a sore thumb and means that you need to invert the bus numbering when connecting it to external memory. Internally, when programming these things, you get the joys of figuring out which bits are which in the documentation, and how that corresponds to reality. The manual might tell you a hardware register is theoretically 64 bits, with the field you are interested in from bits 56 to 59. However, perhaps only the lower 32 bits of the register are implemented, so the actual bits are 24 to 27. You then have to translate this into sensible bit numbers, 4 to 7, so that you can use them in software. All in all, reverse bit numbering is a big waste of time and effort, and a big cause of mistakes. And for PPC devices (at least, those I have looked at) with 64-bit architectures, the external databus is numbered consistently with the 32-bit devices. Thus the LSB of the data and address buses stays at 31. So the upper half of the databus runs from D-1 to D-32 as the MSB. Internally, of course, the registers are numbered with bit 0 as the MSB and bit 63 as the LSB. Thus bit 0 in a data register corresponds to pin D-32 on the PPC, matching net D63 on any external memory bus. Yes, "nice and consistent" is just the phrase... > In actual coding, (software) one can write a loop in whichever > way one wants. The hardware will execute it independent of the > thought process of the programmer. > I was under the impression that programming was about getting the hardware to execute /dependent/ on the thoughts of the programmer! > It never confused me. > I've not use the Power architecture, only some PowerPC devices, but I have to admit it has confused me on occasion, and irritated and frustrated me more often than that. mvh., David
From: rickman on 22 Oct 2009 14:09 On Oct 20, 4:09 pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > rickman <gnu...(a)gmail.com> wrote: > > On Oct 20, 3:21?pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > > (snip) > > >> IBM consistently numbered the MSB 0 on S/360, S/370, XA/370, > >> ESA/370, ESA/390, and z/Architecture. > > (snip) > > >> Even more, z/ can operate on code using 64, 31, or 24 bit addressing > >> as appropriate, and instructions change as the addressing mode changes.. > > How are the bits in the address bus numbered? I would find it > > extremely confusing to deal with an address where the lsb is numbered > > N where N varies depending on the size of the address range. > > If by 'address bus' you mean the physical hardware, that is a separate > question from the architecture. > > Otherwise, the numbering changed in z/, but is internally consistent. > > For S/360, 24 bit addresses are in bits 8 to 31 of general registers, > for example, and the address as stored in the PSW is bits 40 to 63. > > z/ extended to 64 bits, so 24 bit addresses are in bits 40 to 63, > 31 bit in 33 to 63, and 64 bit addresses in bits 0 to 63. > > That only comes up in reading the descriptions of the instructions. > > In actual coding, (software) one can write a loop in whichever > way one wants. The hardware will execute it independent of the > thought process of the programmer. > > It never confused me. > > -- glen This discussion has been about the hardware from the first post. I don't care much what people do in their heads with a programming language. We were talking about connecting different buses in the hardware. One was numbered 15 downto 0, IIRC and the other was 0 to 31. If I understood the OP's problem, he was connecting the two buses incorrectly. His real problem was that he was thinking his problem was something to do with how the language interprets negative numbers in the various data types. In reality, I think he was confused about how to connect a 16 bit bus to a 32 bit bus and preserve sign. We haven't heard back from him, so I'm not sure how he fixed it. Rick
From: rickman on 22 Oct 2009 14:14
On Oct 21, 7:16 am, David Brown <da...(a)westcontrol.removethisbit.com> wrote: > glen herrmannsfeldt wrote: > > rickman <gnu...(a)gmail.com> wrote: > >> On Oct 20, 3:21?pm, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > > (snip) > > >>> IBM consistently numbered the MSB 0 on S/360, S/370, XA/370, > >>> ESA/370, ESA/390, and z/Architecture. > > > (snip) > >>> Even more, z/ can operate on code using 64, 31, or 24 bit addressing > >>> as appropriate, and instructions change as the addressing mode changes. > > >> How are the bits in the address bus numbered? I would find it > >> extremely confusing to deal with an address where the lsb is numbered > >> N where N varies depending on the size of the address range. > > > If by 'address bus' you mean the physical hardware, that is a separate > > question from the architecture. > > > Otherwise, the numbering changed in z/, but is internally consistent. > > > For S/360, 24 bit addresses are in bits 8 to 31 of general registers, > > for example, and the address as stored in the PSW is bits 40 to 63. > > > z/ extended to 64 bits, so 24 bit addresses are in bits 40 to 63, > > 31 bit in 33 to 63, and 64 bit addresses in bits 0 to 63. > > > That only comes up in reading the descriptions of the instructions. > > This is "nice and consistent" ?? The bit numbering for the same address > varies according to the size of the register, and the significance of a > bit of a given number varies according to the register, the bit width, > and the machine variant. I'll agree that much of this is hidden from > the programmer, and that you can get used to it, but it's still > inconsistent and it's still messy. > > I've dealt with this in the context of PPC microcontrollers - it is a > big pain in the neck, and it's very easy to get wrong. Virtually > everything else in the electronics world numbers bits consistently from > 0 for the LSB - the PPC sticks out like a sore thumb and means that you > need to invert the bus numbering when connecting it to external memory. > Internally, when programming these things, you get the joys of > figuring out which bits are which in the documentation, and how that > corresponds to reality. The manual might tell you a hardware register > is theoretically 64 bits, with the field you are interested in from bits > 56 to 59. However, perhaps only the lower 32 bits of the register are > implemented, so the actual bits are 24 to 27. You then have to > translate this into sensible bit numbers, 4 to 7, so that you can use > them in software. All in all, reverse bit numbering is a big waste of > time and effort, and a big cause of mistakes. > > And for PPC devices (at least, those I have looked at) with 64-bit > architectures, the external databus is numbered consistently with the > 32-bit devices. Thus the LSB of the data and address buses stays at 31.. > So the upper half of the databus runs from D-1 to D-32 as the MSB. > Internally, of course, the registers are numbered with bit 0 as the MSB > and bit 63 as the LSB. Thus bit 0 in a data register corresponds to pin > D-32 on the PPC, matching net D63 on any external memory bus. > > Yes, "nice and consistent" is just the phrase... > > > In actual coding, (software) one can write a loop in whichever > > way one wants. The hardware will execute it independent of the > > thought process of the programmer. > > I was under the impression that programming was about getting the > hardware to execute /dependent/ on the thoughts of the programmer! > > > It never confused me. > > I've not use the Power architecture, only some PowerPC devices, but I > have to admit it has confused me on occasion, and irritated and > frustrated me more often than that. > > mvh., > > David I didn't realize that the microBlaze used a little endian bus numbering convention. That is a good reason to avoid it... a small reason, but a reason nonetheless. Actually, the main reason to avoid proprietary IP like microBlaze is the fact that it is proprietary. I prefer to use one of the available CPUs that are open source and can be ported to chips from any vendor or even an ASIC. Rick |