#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
Bit stuffing/shifting on teletype
#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
#21

I understand if i have to ask what this brings to Teletype that I’m too early in the process of working with more complex operations with the device, all the same could someone explain this like I’m five?

#22

Are you asking what bitwise operations are in general, or why we’d want them in teletype?