(Teletype) Bitwise Operators (Done!)

Monome
1

One thing that might be handy to convert some aspect of a number into a rhythmic value, perhaps the teletype could benefit from an operator to return the status of each bit in the number.

Example:

A CHAOS
IF BIT 1 A: TR.P 1
IF BIT 2 A: TR.P 2
IF BIT 3 A: TR.P 3
IF BIT 4 A: TR.P 4

I understand that this could be done using existing syntax, but I think that the addition of cellular automata to teletype via the CHAOS operator calls for an easier way to access the bits of a value.

Implemented for 2.2:

| A B
& A B
BSET A B
BCLR A B
BGET A B
2 Likes
2

would be great to also have a corresponding setter

1 Like
3

bitwise ops, you mean? we’ve discussed this in the past and i think it’s a good candidate. so BIT is a bitwise AND, with a helper shift on the first arg.

i’d be more up for a straight bitwise AND, it’d be more flexible. ie

AND* 3 X

returns the two rightmost bits of X. i’m not sure how to differentiate bitwise vs. logical (logical ops already exist for these).

re: setter.

set bit 1 to 1:

X OR* 1 X

clear bit 8:

X AND* 128 X

equivalent to:

X AND* LSH 1 8 X

alternatives:

GET* n X
SET* n X
CLR* n X

any thoughts?

3 Likes
4

i really like the readability and user friendliness of GET\SET\CLR. do we need to include *?

it would be great to also have regular bitwise ops though. maybe just & and |?

2 Likes
5

I vote for plain GET, SET, and CLR. If we need to make it more clear, maybe BSET or SETB?

I’m for this as well.

1 Like
6

i think set/get/clr are way too ambiguous without adding an indicator that they are for bits.

so BSET/BGET/BCLR are fine by me. so is | and &

2 Likes
7

BGET 3 A is certainly more readable than MOD RSH A 2 2 :slight_smile:

should it be BGET n X or BGET X n? the latter feels a bit more natural.

2 Likes
8

I guess the latter fits with the existing ops better, so it gets my vote.

1 Like
9

that was my thought, since it matches LSH\RSH X n and such.

10

Pull request #126 opened with this functionality.

Test build: teletype.hex (355.4 KB)

1 Like
11

looked at the PR, couple of comments:

  • it probably makes more sense for n to be 0 based
  • should we also add a bitwise NOT? as ~?
2 Likes
12

I can do bitwise NOT as ~, sure! Good call.

As to bit indexing, I don’t know why I was thinking it should be 1-based. Working between two programming languages crosses my wires about conventions sometimes.

I’ll wait for @tehn to weigh in, but you’re probably right.

1 Like
13

yes, 0 based.

ie

X & (1 << n)

bitwise not, excellent! to be clear, ~ only takes a single arg, yeah? if we’re going all the way, ^ for xor?

3 Likes
14

Re: bitwise not ~

Given that bitwise not of a signed integer is not very useful, maybe the not should be performed in an unsigned manner? I.e.:

sign = x < 0 ? -1 : 1;
x = ( ~ (x * sign)) * sign;

note this breaks for -32768

It’s an odd problem.

15

guess i’d vote for having it do the obvious thing - flip all the bits including sign.

~(-256) = 255
~(-2) = 1
~(-1) = 0

2’s-complement is standard enough that breaking it would violate principle of least surprise…

let’s see, the alternative:

would mean, in int16, that ~(-1) = -1 * (~1) = -1 * 0xfffe = … 2? i feel weird.

1 Like
16

Alternate would be illogical, as would all negative numbers. I shouldn’t have written that up. It’s wrong and bad and it was too late in the day.

I thought that NOT wouldn’t make sense to users in a signed context, but I guess it only makes sense to use that along with BGET.

My bad!

17

inverting all the bits makes most sense, when using bitwise ops i would likely treat values as 32 bit unsigned ints (say, as a way to pack 32 step trigger sequence into a pattern value).

edit: 16, not 32… coffee!

2 Likes
18

PR Updated with NOT and XOR, zero-based bit indexing.

Test Build: teletype.hex (356.0 KB)

2 Likes
19

Bitwise AND, NOT, OR and XOR would be really nice

20

They’re all there in 2.2-beta. Got hashed out in another thread. Full set:

BGET, BSET, BCLR, &, |, ~, ^
2 Likes