problem while receiving negative integer in microblaze

On Oct 19, 9:58=A0am, Gabor <ga...@alacron.com> wrote:
> On Oct 16, 6:59=A0pm, rickman <gnu...@gmail.com> wrote:
>
>
>
> > On Oct 15, 1:10=A0pm, Andy Peters <goo...@latke.net> wrote:
>
> > > On Oct 15, 8:14=A0am, rickman <gnu...@gmail.com> wrote:
>
> > > > On Oct 15, 12:51=A0am, GrIsH <grishkun...@gmail.com> wrote:
>
> > > > > On Oct 14, 11:35=A0am, rickman <gnu...@gmail.com> wrote:
>
> > > > > > I have never worked with SLV in the 0 to N direction. =A0To be =
honest, I
> > > > > > don't remember the details of how assignments are made between =
buses
> > > > > > using different directions of indexes. =A0I wouldn't expect any
> > > > > > surprises, but then I have no experience with them. =A0Is there=
 a reason
> > > > > > that you are using 0 to N numbering instead of N downto 0 on yo=
ur SLV
> > > > > > arrays? =A0This may not be a problem, but if you are stuck, why=
 use this
> > > > > > uncommon convention?
>
> > > > > =A0 =A0 for IP2Bus_Data we are not allowed to make this conventio=
n of N
> > > > > downto 0 that's why i didn't use this convention.
>
> > > > Ok, it shouldn't matter really, as long as you use it correctly. =
=A0Can
> > > > you explain what this bus is and why it is 0 to 31? =A0Is this a po=
rt on
> > > > the uBlaze? =A0Where exactly does this restriction come from. =A0Wh=
y do
> > > > you assign your counter result to bits 16 to 31?
>
> > > MicroBlaze is big endian. Bits 16 to 31 are the two least significant
> > > bytes in a 32-bit word (bit 31 is the right-most bit).
>
> > > -a
>
> > I wonder why they do that. =A0I have only seen bit zero as the most
> > significant bit in a handful of designs and I expect the first was
> > done for fairly obscure reasons and the rest were done to be
> > compatible. =A0Did the uBlaze need to be compatible with something in
> > this regard?
>
> > Rick
>
> The historical reason is that IBM's Power PC is big endian, so
> all of the V2 pro tools were big endian, and microBlaze came
> later. =A0Sticking with big endian at that stage in the game
> was better than re-writing a bunch of supporting software.
>
> Regards,
> Gabor

Are you saying that on the Power PC they number bits in the data bus
with 0 as msb and 31 as lsb?  How about address bits, is the lsb
numbered 31 and the msb numbered 0?  I would find that very
confusing.

I could care less if the byte addressing is big-endian or little-
endian.  I don't see that having much import when defining the bits in
a bus.

Rick

rickman <gnuarm@gmail.com> writes:

> On Oct 19, 9:58&#4294967295;am, Gabor <ga...@alacron.com> wrote:
> Are you saying that on the Power PC they number bits in the data bus
> with 0 as msb and 31 as lsb?  How about address bits, is the lsb
> numbered 31 and the msb numbered 0?  

Yes.  And IIRC on the Motorola 88110 which preceded it, on which the
PowerPC 601 was based (buswise anyway).

> I would find that very confusing.
>
> I could care less if the byte addressing is big-endian or little-
> endian.  I don't see that having much import when defining the bits in
> a bus.
>

If you look at address 0, it corresponds with bits 0 to 7 of the data
bus, address 1 is bits 8 to 15.  Just like on a little-endian processor.
(Would you want address 0 on bits 31 downto 24?  Maybe?)

Anyway, once they've taken that convention, making the address bus
numbered the same way makes more sense than making it opposite to the
databus!

(But nothing beats the SHARC DSP booting from an 8 bit EPROM on bits 16-23 of
the 48 bit address bus :)

Cheers,
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html

On Oct 20, 8:32=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> rickman <gnu...@gmail.com> writes:
> > On Oct 19, 9:58=A0am, Gabor <ga...@alacron.com> wrote:
> > Are you saying that on the Power PC they number bits in the data bus
> > with 0 as msb and 31 as lsb? =A0How about address bits, is the lsb
> > numbered 31 and the msb numbered 0? =A0
>
> Yes. =A0And IIRC on the Motorola 88110 which preceded it, on which the
> PowerPC 601 was based (buswise anyway).
>
> > I would find that very confusing.
>
> > I could care less if the byte addressing is big-endian or little-
> > endian. =A0I don't see that having much import when defining the bits i=
n
> > a bus.
>
> If you look at address 0, it corresponds with bits 0 to 7 of the data
> bus, address 1 is bits 8 to 15. =A0Just like on a little-endian processor=
.
> (Would you want address 0 on bits 31 downto 24? =A0Maybe?)
>
> Anyway, once they've taken that convention, making the address bus
> numbered the same way makes more sense than making it opposite to the
> databus!
>
> (But nothing beats the SHARC DSP booting from an 8 bit EPROM on bits 16-2=
3 of
> the 48 bit address bus :)
>
> Cheers,
> Martin
>
> --
> martin.j.thomp...@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://w=
ww.conekt.net/electronics.html

By the way the "hard" big endian numbering was IBM's not Motorola's.
The
Power-PC originated at IBM and was later a joint venture with
Motorola.
Motorola's own processors, 68K series, use a mix of big endian byte
numbering
and little endian bit numbering, so in fact bits 31:24 of a 32-bit
word
on a 32-bit bus would be byte 0.

How did we get on this topic?

Regards,
Gabor

On Oct 20, 8:32=A0am, Martin Thompson <martin.j.thomp...@trw.com> wrote:
> rickman <gnu...@gmail.com> writes:
> > On Oct 19, 9:58=A0am, Gabor <ga...@alacron.com> wrote:
> > Are you saying that on the Power PC they number bits in the data bus
> > with 0 as msb and 31 as lsb? =A0How about address bits, is the lsb
> > numbered 31 and the msb numbered 0? =A0
>
> Yes. =A0And IIRC on the Motorola 88110 which preceded it, on which the
> PowerPC 601 was based (buswise anyway).
>
> > I would find that very confusing.
>
> > I could care less if the byte addressing is big-endian or little-
> > endian. =A0I don't see that having much import when defining the bits i=
n
> > a bus.
>
> If you look at address 0, it corresponds with bits 0 to 7 of the data
> bus, address 1 is bits 8 to 15. =A0Just like on a little-endian processor=
.
> (Would you want address 0 on bits 31 downto 24? =A0Maybe?)
>
> Anyway, once they've taken that convention, making the address bus
> numbered the same way makes more sense than making it opposite to the
> databus!
>
> (But nothing beats the SHARC DSP booting from an 8 bit EPROM on bits 16-2=
3 of
> the 48 bit address bus :)

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?

Rick

rickman <gnuarm@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

On Oct 20, 3:21=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip)
>
> > Why would I care what the numeric name of the bits for a given byte
> > are? =A0I 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. =A0Do the big endian processors do that as
> > well? =A0Is 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. =A0The 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

rickman <gnuarm@gmail.com> wrote:
> On Oct 20, 3:21?pm, glen herrmannsfeldt <g...@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

glen herrmannsfeldt wrote:
> rickman <gnuarm@gmail.com> wrote:
>> On Oct 20, 3:21?pm, glen herrmannsfeldt <g...@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

On Oct 20, 4:09=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
> > On Oct 20, 3:21?pm, glen herrmannsfeldt <g...@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? =A0I 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. =A0
>
> 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. =A0The 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

On Oct 21, 7:16=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> glen herrmannsfeldt wrote:
> > rickman <gnu...@gmail.com> wrote:
> >> On Oct 20, 3:21?pm, glen herrmannsfeldt <g...@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 change=
s.
>
> >> How are the bits in the address bus numbered? =A0I 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. =A0
>
> > 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" ?? =A0The bit numbering for the same addres=
s
> 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. =A0I'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. =A0Virtually
> 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.
> =A0 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. =A0The manual might tell you a hardware register
> is theoretically 64 bits, with the field you are interested in from bits
> 56 to 59. =A0However, perhaps only the lower 32 bits of the register are
> implemented, so the actual bits are 24 to 27. =A0You then have to
> translate this into sensible bit numbers, 4 to 7, so that you can use
> them in software. =A0All 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. =A0Thus the LSB of the data and address buses stays at 31=
.
> =A0 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. =A0Thus bit 0 in a data register corresponds to pi=
n
> 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. =A0The 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