News:

  • October 17, 2026, 05:29:41 PM

Login with username, password and session length

Author Topic: Feature suggestion -- expanded pointer addressing  (Read 9128 times)

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3628
  • Darth Ladder
Feature suggestion -- expanded pointer addressing
« on: March 28, 2021, 03:32:04 PM »
Expansion of free form expressions as indices has been discussed a few times, but I know it's a big deal.

I realized that many times when I'm using a MATH  box to get free expressions, it's only to use something other than Vxx + offset as an index, but not a full on complex expression.

Would it be an easier intermediate  step to allow other types of memory in addition to V?  So for example, MHR + offset would be legal in compares, contacts, etc?
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3628
  • Darth Ladder
Re: Feature suggestion -- expanded pointer addressing
« Reply #1 on: March 28, 2021, 04:00:58 PM »
Or possibly, if explicitly cast as unsigned like MHRxx:UW
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3850
    • Host Engineering
Re: Feature suggestion -- expanded pointer addressing
« Reply #2 on: March 29, 2021, 01:28:06 PM »
Expansion of free form expressions as indices has been discussed a few times, but I know it's a big deal.

I realized that many times when I'm using a MATH  box to get free expressions, it's only to use something other than Vxx + offset as an index, but not a full on complex expression.

Would it be an easier intermediate  step to allow other types of memory in addition to V?  So for example, MHR + offset would be legal in compares, contacts, etc?

We've kicked around an "Expression" contact - which I think would address your need.  Basically, if the result of the expression is non-zero, the contact is true.  Hence, you would not even need to use a relational operator in it, you could just do something like

Code: [Select]
D[SQRT(R27) + 42 - T0.Acc] & (0x0001 << (V99 - 1))
----------------------] E [-----------------------

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3628
  • Darth Ladder
Re: Feature suggestion -- expanded pointer addressing
« Reply #3 on: March 29, 2021, 02:28:07 PM »
Yes, that would definitely be cool.    Given the option I'd take the expansion of simple pointers but with elimination of the V restriction instead though.

The other day I did

Code: [Select]
STR ST1
MATH DST511 "MC2532" "Y[MHR12]"

where with the thing I'm asking for I'd have been able to do

STR MC2532 OUT Y[MHR12]

BUT.....if you have a higher priority on the expression contact, I'll definitely take it!   :D


I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6177
  • Yes Pinky, Do-more will control the world!
Re: Feature suggestion -- expanded pointer addressing
« Reply #4 on: March 29, 2021, 03:02:01 PM »
The V dependency is structural. The only way around it is expressions.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

Controls Guy

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 3628
  • Darth Ladder
Re: Feature suggestion -- expanded pointer addressing
« Reply #5 on: March 29, 2021, 03:26:27 PM »
The V dependency is structural. The only way around it is expressions.

OK, got it.   Thanks!   
I retract my earlier statement that half of all politicians are crooks.  Half of all politicians are NOT crooks.  There.