Appending Bits to a String
- Thread starter ReAn
- Start date
ReAn
Dangerous Programmer...
- Local time
- Today, 15:50
- Joined
- Jun 25, 2004
- Messages
- 250
Yes, I mean bits, im building an algorithm that calls for a specific number of padded bits so that the input string has a specific size.
I need to add BITS..
Would be freakin simple in c/c++ just bitshift left and add one.
I need to add BITS..
Would be freakin simple in c/c++ just bitshift left and add one.
ReAn,
Need more info.
How can you add 3 bits? Do you mean that you want to concatenate
something like x0FFE (hex) to the end of a string?
That seems to call for adding characters.
InputString = InputString & Space(DesiredLength - Len(InputString))
Confusedly yours,
Wayne
Need more info.
How can you add 3 bits? Do you mean that you want to concatenate
something like x0FFE (hex) to the end of a string?
That seems to call for adding characters.
InputString = InputString & Space(DesiredLength - Len(InputString))
Confusedly yours,
Wayne
you can use Space() to allocate a string of a given number of characters, but i don't know of any way to manipulate strings at the bit level. Space() could help you though if you need to pad out to a byte boundary.
myStr = Space(63) 'a string w/ 63 characters
what does your function do? what information does the string represent?
myStr = Space(63) 'a string w/ 63 characters
what does your function do? what information does the string represent?
ReAn
Dangerous Programmer...
- Local time
- Today, 15:50
- Joined
- Jun 25, 2004
- Messages
- 250
Ive worked out that whole problem now (had to do many binary->decimal->binary conversions)
Now i need to know what type is a 4 byte number.
I think integer is a 2 byte... but i'll ask you all:
What is a 4 byte storage type, Double, long, integer... ect...
Now i need to know what type is a 4 byte number.
I think integer is a 2 byte... but i'll ask you all:
What is a 4 byte storage type, Double, long, integer... ect...
, my algorithm calls for unsigned addition of 4byte numbers >_<
- Local time
- Today, 16:50
- Joined
- Feb 28, 2001
- Messages
- 30,395
ReAn
There is NO DIFFERENCE in the algorithm for adding signed or unsigned numbers EXCEPT the error handling. The operations are the same in binary for signed or unsigned numbers. The OVERFLOW condition, however, becomes an issue. You would have to set an error trap around the code that adds the LONG integers. If the error code detects that the output number changed sign based on the input values, and the NEW value appears to be negative, you are OK - but if it was the OLD value that was negative, you had a bitwise overflow out of bit 31 (MSB of a LONG integer).
Now, to answer the original question. Technically, you CANNOT add bits to a string because VBA's string paradigm is NOT C++'s string paradigm. VBA says all strings are bytes. Eight bits. No questions, no foolin', no problem.
When you want to SIMULATE another language or system's behavior, you have to remember that what you want to do should be simulated storage-unit by storage-unit. And by the way, despite the apparent ease of doing what you wanted in C++, you are STILL working in BYTES. It is just that the language's string paradigm allows you to APPEAR to be doing something else. But you really aren't.
Most hardware these days won't let you muck with individual bits unless you allocated an entire byte to hold the "new" bits you were adding. I know the instruction code behind most Intel-based boxes (and Motorola, too). They don't like bitwise manipulation either. Bytewise masking, AND, OR, NOT, XOR, etc, ... but no true bit twiddling. The last machine I personally know for a fact to have had this ability was a VAX, and Access won't run there, so it's a moot point.
There is NO DIFFERENCE in the algorithm for adding signed or unsigned numbers EXCEPT the error handling. The operations are the same in binary for signed or unsigned numbers. The OVERFLOW condition, however, becomes an issue. You would have to set an error trap around the code that adds the LONG integers. If the error code detects that the output number changed sign based on the input values, and the NEW value appears to be negative, you are OK - but if it was the OLD value that was negative, you had a bitwise overflow out of bit 31 (MSB of a LONG integer).
Now, to answer the original question. Technically, you CANNOT add bits to a string because VBA's string paradigm is NOT C++'s string paradigm. VBA says all strings are bytes. Eight bits. No questions, no foolin', no problem.
When you want to SIMULATE another language or system's behavior, you have to remember that what you want to do should be simulated storage-unit by storage-unit. And by the way, despite the apparent ease of doing what you wanted in C++, you are STILL working in BYTES. It is just that the language's string paradigm allows you to APPEAR to be doing something else. But you really aren't.
Most hardware these days won't let you muck with individual bits unless you allocated an entire byte to hold the "new" bits you were adding. I know the instruction code behind most Intel-based boxes (and Motorola, too). They don't like bitwise manipulation either. Bytewise masking, AND, OR, NOT, XOR, etc, ... but no true bit twiddling. The last machine I personally know for a fact to have had this ability was a VAX, and Access won't run there, so it's a moot point.
ChrisO
Registered User.
- Local time
- Tomorrow, 07:50
- Joined
- Apr 30, 2003
- Messages
- 3,202
Sorry for the late reply.
Doc…if I understand your reply, I would like to expand a little.
(You don’t need this reply.)
A bit (pun intended) of a forward.
I worked for a large US instrumentation company, The Foxboro Company, and was their service manager for a ‘few’ years in Sydney. But I also did other software and hardware work for them as well. So I too come from a hardware and software background and over about the same period as you. (It would seem???)
Interesting observation (on your part) about the language, even machine code, and the underlying hardware.
Starting almost 30 years ago the Foxboro Company used the AMD 2901 4-bit slice sequencer, and designed, in-house, its own machine code. (And high level languages.)
(Form keyboards to mini computers, 2 to 6 wide. All great hardware and software.)
(The difference between a sequencer and a microprocessor was/is that the sequencer had its instruction set defined in external ROM. The end user could therefore design their own instruction set.)
All had machine code memory reference instruction sets that contained ‘Set Bit N’ and ‘Clear Bit N’ instructions, and programmers thought… ‘that is how it works.’
But it ain’t.
The ability of software to access hardware is ultimately restricted by hardware.
Even for machine code instructions to ‘Set Bit N’ in memory, they would require ‘Bit addressing’ in hardware. (But the address bus is not that wide.)
That is not common.
What happens in this case is that the machine code states ‘Set Bit N’ in memory.
Underlying micro-code then fetches the smallest amount of data from memory to a register. (As you say correctly…probably a byte.)
The micro-code then carries out the logic function, unconditionally.
After the logic function is performed, the register is written back to memory.
Therefore, ‘Set Bit N’ in memory becomes three machine cycles. Read, modify, and write.
There was an exception…
DEC PDP 11’s, amongst others, used magnetic core memory. A read of magnetic core caused the destruction of the contents of that memory address i.e. it was set to zero. Therefore, in magnet core systems, each ‘non destructive’ read had to be written back to the same address, and that takes time.
Therefore for speed, DEC PDP 11’s, and 8’s as well, cleared memory by simply doing a read and no write back. In fact all core memory read/modify/write instructions saved time by not trying to preserve memory contents. Reason? It would be overwritten by the write back phase of the instruction after the modify phase.
All this happens below ‘Basic’, below ‘C’, below ‘Assembly Language’, even below ‘Machine Code’ but at the micro-code level. It happens at a level we can not generally enter. It happens in micro-code and that is based on hardware.
Doc…can this be done on a VAX?
Just a thought and still curious after all these years???
Regards,
Chris.
Doc…if I understand your reply, I would like to expand a little.
(You don’t need this reply.)
A bit (pun intended) of a forward.
I worked for a large US instrumentation company, The Foxboro Company, and was their service manager for a ‘few’ years in Sydney. But I also did other software and hardware work for them as well. So I too come from a hardware and software background and over about the same period as you. (It would seem???)
Interesting observation (on your part) about the language, even machine code, and the underlying hardware.
Starting almost 30 years ago the Foxboro Company used the AMD 2901 4-bit slice sequencer, and designed, in-house, its own machine code. (And high level languages.)
(Form keyboards to mini computers, 2 to 6 wide. All great hardware and software.)
(The difference between a sequencer and a microprocessor was/is that the sequencer had its instruction set defined in external ROM. The end user could therefore design their own instruction set.)
All had machine code memory reference instruction sets that contained ‘Set Bit N’ and ‘Clear Bit N’ instructions, and programmers thought… ‘that is how it works.’
But it ain’t.
The ability of software to access hardware is ultimately restricted by hardware.
Even for machine code instructions to ‘Set Bit N’ in memory, they would require ‘Bit addressing’ in hardware. (But the address bus is not that wide.)
That is not common.
What happens in this case is that the machine code states ‘Set Bit N’ in memory.
Underlying micro-code then fetches the smallest amount of data from memory to a register. (As you say correctly…probably a byte.)
The micro-code then carries out the logic function, unconditionally.
After the logic function is performed, the register is written back to memory.
Therefore, ‘Set Bit N’ in memory becomes three machine cycles. Read, modify, and write.
There was an exception…
DEC PDP 11’s, amongst others, used magnetic core memory. A read of magnetic core caused the destruction of the contents of that memory address i.e. it was set to zero. Therefore, in magnet core systems, each ‘non destructive’ read had to be written back to the same address, and that takes time.
Therefore for speed, DEC PDP 11’s, and 8’s as well, cleared memory by simply doing a read and no write back. In fact all core memory read/modify/write instructions saved time by not trying to preserve memory contents. Reason? It would be overwritten by the write back phase of the instruction after the modify phase.
All this happens below ‘Basic’, below ‘C’, below ‘Assembly Language’, even below ‘Machine Code’ but at the micro-code level. It happens at a level we can not generally enter. It happens in micro-code and that is based on hardware.
Doc…can this be done on a VAX?
Just a thought and still curious after all these years???
Regards,
Chris.
Last edited:
Chris,
Wow! Had to get out my old PDP-11 programming card. The PDP-11
supported:
ROR - Rotate Right
ROL - Rotate Left
ASR - Arithmetic Shift Left
ASL - Arithmetic Shift Right
BIT - Bit Test
BIC - Bit Clear
BIS - Bit Set
The VAX was more or less the big brother to the PDP, so I'm quite
sure it supported these also.
Used to do a lot of MACRO-11, could "read" machine code for that
beast. Even wrote a PASCAL program to turn an IBM 360 into a PDP-11.
Never did see a PDP with magnetic core though. Plenty of other
hulks with core memory and paper tape/mylar readers, punched
cards, etc.
PDP 11/34, 256K words (16-bit) of memory, a whopping set of
three 10 MB disks. Used by about a dozen people at once! With
a 64Kbyte address space (Minus: 16Kbytes - file system, 8KB to
map to programming language library). Overlay descriptor files
(.odl) to map address space.
Oh, the good old days!
Wayne
Wow! Had to get out my old PDP-11 programming card. The PDP-11
supported:
ROR - Rotate Right
ROL - Rotate Left
ASR - Arithmetic Shift Left
ASL - Arithmetic Shift Right
BIT - Bit Test
BIC - Bit Clear
BIS - Bit Set
The VAX was more or less the big brother to the PDP, so I'm quite
sure it supported these also.
Used to do a lot of MACRO-11, could "read" machine code for that
beast. Even wrote a PASCAL program to turn an IBM 360 into a PDP-11.
Never did see a PDP with magnetic core though. Plenty of other
hulks with core memory and paper tape/mylar readers, punched
cards, etc.
PDP 11/34, 256K words (16-bit) of memory, a whopping set of
three 10 MB disks. Used by about a dozen people at once! With
a 64Kbyte address space (Minus: 16Kbytes - file system, 8KB to
map to programming language library). Overlay descriptor files
(.odl) to map address space.
Oh, the good old days!
Wayne
- Local time
- Today, 16:50
- Joined
- Feb 28, 2001
- Messages
- 30,395
Well, for those curious about VAXen (which is the preferred plural of VAX),...
VAXen had all of the PDP-11 instructions (well, most of them) plus a few others to muck about with bits directly.
PDP-11 could do a ROR(B) (word or byte Rotate One Right), ROL(B) (word or byte Rotate One Left), ASL(B) (arithmetic shift left word or byte), ASR(B) (arithmetic shift right word or byte), ASH(C) (arithmetic shift register or combined registers) plus ADC(B)/SBC(B) (add or subtract carry to word or byte). You could bit-twiddle with the best of them. Not to mention mask-based instructions like BIS, BIT, and BIC (Bit set, bit test, and bit clear) and XOR (exclusive or). Plus the branch instructions that tested the carry after a rotate, and you could set or clear the carry BEFORE a rotate if you wanted.
But the VAX had even the PDP-11 beat. It included ASH(L/Q) (long/quadword shift), ADWC (add with carry), all of the XOR, BIC, BIS, and BIT for byte, word, & longword, and the king of all bit-twiddlers: the INSV/EXTV (insert/extract bit sub-field). You could define a field as 1 to 32 bits starting anywhere in a longword. Pull the field into a register, muck it about, and drop it back where you found it without touching anything adjacent to it.
Now, many folks didn't know this about VAXen, but there really was only one true VAX for lots of years. That was the 11/750. ALL OTHER VAXEN were microcoded until the VAX mod 3900s came out. Most VAXen were faceless until they loaded their microcode. And it was shown more than once at the old DECus conventions that some wag had programmed the VAX microcode to emulate an IBM 3xx family machine or another CPU as an experiment to prove something or other.
In terms of ability, I still love the old VAXens. But these days, there is something better on the market, even if not quite so approachable as VAX was - the Alpha CPU is pure speed. Due to the teaming agreements worked out between Intel and DEC before DEC got bought out, your modern PCs are about half Alpha inside. Particularly in the L2 cache arena and the instruction pipelining segments. And the new IA64 chip, whatever they finally call it, is about 3/4 Alpha. My home machine, with twin CPUs running at 2.8 GHz, uses Alpha technology to keep its multiprocessing operations running smoothly.
None of which helps anyone who needs to use Access to bit-twiddle today.
VAXen had all of the PDP-11 instructions (well, most of them) plus a few others to muck about with bits directly.
PDP-11 could do a ROR(B) (word or byte Rotate One Right), ROL(B) (word or byte Rotate One Left), ASL(B) (arithmetic shift left word or byte), ASR(B) (arithmetic shift right word or byte), ASH(C) (arithmetic shift register or combined registers) plus ADC(B)/SBC(B) (add or subtract carry to word or byte). You could bit-twiddle with the best of them. Not to mention mask-based instructions like BIS, BIT, and BIC (Bit set, bit test, and bit clear) and XOR (exclusive or). Plus the branch instructions that tested the carry after a rotate, and you could set or clear the carry BEFORE a rotate if you wanted.
But the VAX had even the PDP-11 beat. It included ASH(L/Q) (long/quadword shift), ADWC (add with carry), all of the XOR, BIC, BIS, and BIT for byte, word, & longword, and the king of all bit-twiddlers: the INSV/EXTV (insert/extract bit sub-field). You could define a field as 1 to 32 bits starting anywhere in a longword. Pull the field into a register, muck it about, and drop it back where you found it without touching anything adjacent to it.
Now, many folks didn't know this about VAXen, but there really was only one true VAX for lots of years. That was the 11/750. ALL OTHER VAXEN were microcoded until the VAX mod 3900s came out. Most VAXen were faceless until they loaded their microcode. And it was shown more than once at the old DECus conventions that some wag had programmed the VAX microcode to emulate an IBM 3xx family machine or another CPU as an experiment to prove something or other.
In terms of ability, I still love the old VAXens. But these days, there is something better on the market, even if not quite so approachable as VAX was - the Alpha CPU is pure speed. Due to the teaming agreements worked out between Intel and DEC before DEC got bought out, your modern PCs are about half Alpha inside. Particularly in the L2 cache arena and the instruction pipelining segments. And the new IA64 chip, whatever they finally call it, is about 3/4 Alpha. My home machine, with twin CPUs running at 2.8 GHz, uses Alpha technology to keep its multiprocessing operations running smoothly.
None of which helps anyone who needs to use Access to bit-twiddle today.
ChrisO
Registered User.
- Local time
- Tomorrow, 07:50
- Joined
- Apr 30, 2003
- Messages
- 3,202
Sorry ReAn if us ‘old buggers’ have highjacked this thread but we do get a little nostalgic at times. 
Just a suggestion because its been a long time since my last ‘C’ program.
Can Main() return the data type you require?
If so then you may be able to write the function in ‘C’ and pass the arguments to it.
Maybe not the fastest way but it could get the job done.
Regards,
Chris.
Just a suggestion because its been a long time since my last ‘C’ program.
Can Main() return the data type you require?
If so then you may be able to write the function in ‘C’ and pass the arguments to it.
Maybe not the fastest way but it could get the job done.
Regards,
Chris.
