(Teletype) Bitwise Operators (Done!)


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.


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

(teletype) how to "extract" 0s and 1s from numbers?
(Teletype) 2.2 Release
(Teletype) 2.2 Release

would be great to also have a corresponding setter


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


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

any thoughts?


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 |?


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.


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 &


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.


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

Bit stuffing/shifting on teletype

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


Pull request #126 opened with this functionality.

Test build: teletype.hex (355.4 KB)


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 ~?


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.


yes, 0 based.


X & (1 << n)

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


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.


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.


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!


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!


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

Test Build: teletype.hex (356.0 KB)


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


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

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