HUB ram below $400 and in ROM area

I am sort of confused about the current use of HUB memory below $400. As far as I can follow jmps/calls below $400 use LUT ram, below $200 COG ram and above that HUB exec.

But HUB exec does not need to be aligned to longs, so one can HUB exec code on odd addresses for example. Is this still true for HUB exec below $400, so can one call odd addresses in HUB below $400 or is that not true anymore?

Would it make sense to use the same method done on the P1 to save current clock settings of the P2 in the first locations? Or could there be some memory location in the upper ram(rom) that could be used for this?

Is there still a way to write protect the ROM area and unprotect it again or is that not true anymore?

curious,

Mike
I am just another Code Monkey.
A determined coder can write COBOL programs in any language. -- Author unknown.
Press any key to continue, any other key to quit

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.

Comments

  • evanhevanh Posts: 8,271
    edited 2018-11-22 - 03:40:13
    Hehe, I was just about to give the standard answer of, increment of one addressing below $400 works because the addressed cog/lutram is 32-bit sized, ie: Byte addressing turns into longword addressing, and Hubexec vanishes below $400. Only data accesses to hubram down that low.

    But, and that is still true in principal ... but the detail of what an increment of one actually is and what the cut-off address is has become more murky for me of late. Two things have happened that makes me think it needs a little investigating:
    - I remember Cluso stating that the cut-off is $1000, not $400. At the time I corrected him. Now, I'm not so confident. Because just the other day I discovered:
    - The machine coded addresses for cog/lutexec (at least) are padded with %00 for the two lsbits. Meaning a branch to, say $120, is coded as $480. This is cogexec running from cogram.

    It's almost like Pnut is lying about addresses. When the common directive of ORGH $400 is issued, is that actually loading the code to $400 in hubram?

    I haven't thought to question it until now.
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • evanhevanh Posts: 8,271
    edited 2018-11-22 - 03:38:42
    [distracting comment deleted]
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • Hubexec can only run in addresses $400+.
    Melbourne, Australia
  • evanhevanh Posts: 8,271
    edited 2018-11-22 - 03:37:11
    msrobots wrote: »
    Would it make sense to use the same method done on the P1 to save current clock settings of the P2 in the first locations? Or could there be some memory location in the upper ram(rom) that could be used for this?
    Currently, Pnut puts a copy of cog0's initial program there. But that could change as Spin2 gets developed.

    Is there still a way to write protect the ROM area and unprotect it again or is that not true anymore?
    Write protect control is in the HUBSET instruction. Documented in the google doc.

    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • evanhevanh Posts: 8,271
    edited 2018-11-22 - 06:11:46
    evanh wrote: »
    The machine coded addresses for cog/lutexec (at least) are padded with %00 for the two lsbits. Meaning a branch to, say $120, is coded as $480. This is cogexec running from cogram.

    Ah, this might only be true for the 20-bit immediate address encoded in those special instructions ...

    EDIT: Bah! That wouldn't change anything. A jump to encoded address $480 is still inside cogram. How can anything below $1000 be hubexec?
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • evanhevanh Posts: 8,271
    edited 2018-11-22 - 06:51:11
    Has anyone used JMPREL? Pnut seems to have its immediates hard wired to absolute encoding.

    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • cgraceycgracey Posts: 11,908
    edited 2018-11-22 - 07:18:30
    evanh wrote: »
    Has anyone used JMPREL? Pnut seems to have its immediates hard wired to absolute encoding.

    PNut should assemble hub-to-hub references as relative. Same with cog-to-cog. Only when crossing cog/hub does it default to absolute addressing.

    JMPREL is intended for JMP tables.
  • evanhevanh Posts: 8,271
    edited 2018-11-22 - 08:02:47
    Whatever JMPREL is used for, the description describes a relative action only. Yet when using #label, Pnut always encodes an absolute address. Including for #$
    EEEE 1101011 00L DDDDDDDDD 000110000	JMPREL  {#}D	Jump ahead/back by D instructions. For cogex, PC += D[19:0]. For hubex, PC += D[17:0] << 2.
    
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • evanh wrote: »
    Whatever JMPREL is used for, the description describes a relative action only. Yet when using #label, Pnut always encodes an absolute address. Including for #$
    EEEE 1101011 00L DDDDDDDDD 000110000	JMPREL  {#}D	Jump ahead/back by D instructions. For cogex, PC += D[19:0]. For hubex, PC += D[17:0] << 2.
    

    It's really meant to be used with a variable. If you use #label, it will assemble that label's value. There is really no use for an immediate in that instruction, but I allowed it because the hardware allows it. On the other hand, it could be convenient to do 'JMPREL #4' to jump over four instructions.
  • cgracey wrote: »
    PNut should assemble hub-to-hub references as relative. Same with cog-to-cog. Only when crossing cog/hub does it default to absolute addressing.

    Ah, I think I've solved it. In cogram, the relative addresses are different scale to absolute! And this doesn't matter for the purposes of overlap because relative is never used to cross the boundary.

    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
  • And that probably explains the origin of the buggy relative calculation of certain LOC references.
    We have the vastness of the internet and yet billions of people decided to spend most of their time within a horribly designed, fake-news emporium of a website that sucks every possible piece of personal information out of you so it can sell it to others. And they see nothing wrong with that.
Sign In or Register to comment.