Pascal-ish Syntax for bit access.

[kupferstecher]

Molly, thanks for the example!

Its getting closer, but still with drawbacks.

Code: Pascal  [Select][+][-]

1.  bByte:= UDR;  // this is assignment compatible using absolute modifier

The absolute modifier always needs a second variable name, right? (aByte + bByte or UDR + UDRbits ). Thats very unconvenient in my opinion. It seems the same holds for the variable record and also for Thaddys proposal using a set (if I understood correctly). The same with using the bitpacked array or the bitpacked record.

The operator overload of ":=" does work partially, below two common statements:

Code: Pascal  [Select][+][-]

1.   UCSRB:= (1 shl TXEN) or (1 shl RXEN) or (1 shl RXCIE); //Works!
2.   UCSRB:= UCSRB and %00001111; //Error: Operator is not overloaded

The type helper I don't really understand. There only procedures could be used, right? So only bit names could be defined and not bit numbers? In using numbers I see the advantage, that the bit definitions could be done just by constants like it is done in the device definitions for assembler.

Edit: Correct me if I did state anything wrong.

[Thaddy]

The absolute is declared only once, like:
Say I mapped  $20000000 as the address space of  a hardware device.
Then I do  a global var  GPIO = set of Tbytebits absolute $20000000 and GPIO is forever tied to that address. After that you use GPIO just with members of the set, If you need more, you simply declare consecutive banks of Tbytebit like structures. As Marco pointed out: bits are atomic for read/modify/write on most platforms so a global var is OK. And the set members are the bit names ....as per my demo.

[molly]

Molly, thanks for the example!

You're most welcome but, it seems you are still struggling with the concept 

The absolute modifier always needs a second variable name, right? (aByte + bByte or UDR + UDRbits ).

For manipulating another variable of the same size ( pointing at the same locatio )  but of another type, yes. The absolute modifier is not the holy grail there. You asked, i delivered 

Thats very unconvenient in my opinion.

Yes it is very inconvenient, hence using a variant record and a record helper (not type helper, my bad)

It seems the same holds for the variable record and also for Thaddys proposal using a set (if I understood correctly).

No, see above.

The same with using the bitpacked array or the bitpacked record.

You need to start thinking _out_ of the box ;-)

The type helper I don't really understand. There only procedures could be used, right? So only bit names could be defined and not bit numbers?

Well, you could use the type helper to define a default array property 

But, yes. you are correct. I made a boo-boo there, sorry for that.

It should have read record helper but, even then i wrongfully assumed that operators are allowed to be declared therein (which does not seem to be the case).

So, imho, a bitpacked record, or a normal/variant record would be a approach that gives you the most options (which includes the possibility of a default array property and/or enumerator). You can then use record operators instead of global ones.

Edit: Correct me if I did state anything wrong.

You're not the only one doing it wrong, this discussion is messing with my head. for FPC, things are rather simple.

UCSRB:= UCSRB and %00001111; //Error: Operator is not overloaded

C'mon, are we going through the whole list of (bitwise) operators now ? 

Last one then. The rest you need to figure out on your own.

Code: Pascal  [Select][+][-]

1. operator and (x1: TBitByte; x2: TBitByte) Result: TBitByte;
2. var
3.   inval1: Byte absolute x1;
4.   inval2: byte absolute x2;
5.   outval: byte absolute Result;
6. begin
7.   outval := inval1 and inval2;
8. end;
9.  

See also here.

[kupferstecher]

You're most welcome but, it seems you are still struggling with the concept 

Yes, still struggling

C'mon, are we going through the whole list of (bitwise) operators now ? 
Last one then. The rest you need to figure out on your own.

I finally got it~
It means quite some work for all bit arithmetics, arithmetics, comparisons (missed sth.?) and also different integer types (byte, word etc.). But only needs to be done once, so it seems ok.

Using the operator overloadings is clear for me now. Thanks~

The combination variant record and record helper I don't understand exactly. The record helper provides the access to the bitvalues - clear so far. But how to provide direct access to the complete byte? Wouldn't this be the alternate property of the record, with complicated access like 'UDR.value:= 125'?

The absolute is declared only once, like:
[...] and GPIO is forever tied to that address. After that you use GPIO just with members of the set,
[...]
And the set members are the bit names ....as per my demo.

I understood that, but there is no direct access to the value with type 'byte' then, isn't? Thus the problem with type conversion remains. Again with the Operator overloadings described by Molly it works.

[molly]

Yes, still struggling 

Well, at least you gave some good indicators to show some code again. Remember: it is just _a_ solution. There can be many other and depend on your wishes.

It means quite some work for all bit arithmetics, arithmetics, comparisons (missed sth.?) and also different integer types (byte, word etc.). But only needs to be done once, so it seems ok.

Yes, there is a bunch of operators available. So, for every operator that you wish to add support for, you need to add it.

Blame the FPC developers for adding all these operators ?  (*)

The combination variant record and record helper I don't understand exactly.

Ok, let's skip the variant part (it wasn't working the way i wanted to show anyway).

The record helper provides the access to the bitvalues - clear so far.

correct.

But how to provide direct access to the complete byte?

Here, i am starting to think this kind of remark is deliberate to make a point that things do not work 

You wish to have syntax sugar but still want to have direct access. The choice is either the one or the other (or none at all if you prefer  )

Wouldn't this be the alternate property of the record, with complicated access like 'UDR.value:= 125'?

If you wish for direct access to the bytevalue, then yes. If you want to have the syntax sugar then you can use the record operators instead.

Again, a small example:

Code: Pascal  [Select][+][-]

1. program bitsing;
2.  
3. {$MODE OBJFPC}{$H+}
4. {$MODESWITCH ADVANCEDRECORDS}
5.  
6. type
7.   TBitValue = 0..1;
8.   TBitArray = bitpacked array [0..7] of TBitValue;
9.   TBitSing  = record
10.    private
11.      ByteValue : Byte;
12.    public
13.     class operator :=(x: byte): TBitSing;
14.     class operator :=(x: TBitSing): Byte;
15.     class operator :=(x: TBitSing): LongInt;
16.   end;
17.  
18.   TBitSingHelper = record helper for TBitSing
19.    private
20.     function  getbit(BitIndex: integer): TBitValue;
21.     // Overload above function (without index parameter) and (record)-
22.     // enumerator as result in order to add support for an enumerator
23.     procedure setbit(BitIndex: integer; value: TBitValue);
24.    public
25.     property bits[BitIndex: integer]: TBitValue read getbit write setbit; default;
26.   end;
27.  
28.  
29. class operator TBitSing.:=(x: byte): TBitSing;
30. begin
31.   Result.ByteValue := x;
32. end;
33.  
34. class operator TBitSing.:=(x: TBitSing): Byte;
35. begin
36.   Result := x.ByteValue;
37. end;
38.  
39. class operator TBitSing.:=(x: TBitSing): LongInt;
40. begin
41.   result := x.ByteValue;
42. end;
43.  
44. procedure TBitSingHelper.setbit(BitIndex: integer; value: TBitValue);
45. var
46.   ba: TBitArray absolute self.ByteValue;
47. begin
48.   ba[BitIndex mod 8] := value;
49. end;
50.  
51. function  TBitSingHelper.getbit(BitIndex: integer): TBitValue;
52. var
53.   ba: TBitArray absolute self.ByteValue;
54. begin
55.   Result := ba[BitIndex mod 8]
56. end;
57.  
58.  
59. var
60.   x : TBitSing;
61.   y : Byte;
62. begin
63.   x[1] := 1;
64.   y := 100;
65.   x := y;
66.   x.ByteValue := 100;
67.   WriteLn('value of x = ', BinStr(x,8));
68. end.
69.  

So, as you can see there is no need for direct access to the bytevalue, and in case you do wish, it is possible.

Either you use the shortcut syntax sugar, or you don't.

edit: (*) that's what generics are good for ;-)

[avra]

I still think, the best way would be some intrinsic feature of the compiler, to do this, just defining something like:

Code: Pascal  [Select][+][-]

1. VAR
2.   STATUS: byte ABSOLUTE $03  RECORD C , DC, Z, PD, _TO : Bit; RP : 0..3; END;
3.  

This would not be a strange syntax for me to find in a microcontroller pascal compiler.

It's very common to have the type "bit" for small devices compilers.

Users would benefit if you treat bit type compatible with both 0/1 and true/false.

And I like the MODULA 2 syntax, too. Probably I will be including this syntax.

I also prefer it for some stuff.

Currently, I can work with bit variables:

Code: Pascal  [Select][+][-]

1. var
2.   PORTB : byte absolute $06;
3.   pin   : bit absolute PORTB.7;
4. begin                          
5.   pin := 1;
6. end.

This syntax would also be fine for me.

This compiler is intended to target devices as small as PIC16F83, with 512 words of FLASH memory, and 36 bytes of RAM, and probably running at 1MHz or less.

Heh, then you can take a look at old PICco for 16C6x, 16C7x and 16C8x. PICco is the father of AVRco. 
http://www.e-lab.de/PICco/index_en.html

A lot of people in this thread have good intentions and nice ideas, but very few have worked with 8-bit microcontrollers to understand how much 36 bytes of RAM can limit your wishes for a compiler, and how much such limited resources influence compiler design. Anything that adds unnecessary overhead could render your compiler useless for some applications because you would run out of ram or flash space too soon. Then users will turn to C, and we wouldn't like that, would we?

Just keep up the good work, and wish you luck!   

[marcov]

Anything that adds unnecessary overhead could render your compiler useless for some applications because you would run out of ram or flash space too soon. Then users will turn to C, and we wouldn't like that, would we?

The pros will go C anyway to get a better performing compiler, and hobbyists are not tied to those extreme small units. 

Anyway, I think the syntax for terseness is not that important since the headers will be generated from some source (C headers or register map files), and users will rarely manually write such things.

Syntax is not that important, though I would stick to 0 and 1 as default, or have a separate boolean bit field for the ones that want to pascallize everything.

There are much more interesting questions like bit level normal variables (auto packed by compiler/linker). No absolute tricks necessary, just define as (multi) bit and let the compiler/linker pack them into bytes and access them using the bit instructions.

And if I have an incoming (e.g. serial) buffer of say 20 bytes, how do I check  bit _TO in buffer[somevalue] ?

[Thaddy]

The pros will go C anyway to get a better performing compiler, and hobbyists are not tied to those extreme small units. 
[somevalue] ?

Where are the times that every hardware came with pascal compilers, examples and libraries?
That C word argument is not true in general. The languages are too close to call on the basic level. (Pascal vs C, not Object Pascal vs C++)
Or are you simply referring to current *implementations*?
Well, the subject is about implementing one, soooo....

[marcov]

The pros will go C anyway to get a better performing compiler, and hobbyists are not tied to those extreme small units. 
[somevalue] ?

Where are the times that every hardware came with pascal compilers, examples and libraries?

Firmly in the past.

That C word argument is not true in general.

All microprocessor vendors advocate their own C compilers.

The languages are too close to call on the basic level. (Pascal vs C, not Object Pascal vs C++)

I didn't make it about language, I said compiler. If you have so little flash, every instruction counts.

Or are -you simply referring to current *implementations*?

A compiler is an implementation of a language, and I said they would go with a better performing C compiler. Not a better performing C language.
 
Or: simple reality.

[molly]

A lot of people in this thread have good intentions and nice ideas, but very few have worked with 8-bit microcontrollers to understand how much 36 bytes of RAM can limit your wishes for a compiler, and how much such limited resources influence compiler design. Anything that adds unnecessary overhead could render your compiler useless for some applications because you would run out of ram or flash space too soon. Then users will turn to C, and we wouldn't like that, would we?

With all due respect, but if you are limited to 36 bytes of ram then what the hell are you doing with a compiler.

Really, that is just a waste of time.

Just grab a good macro assembler and be done with the thing.

[Edson]

I still think, the best way would be some intrinsic feature of the compiler, to do this, just defining something like:

Code: Pascal  [Select][+][-]

1. VAR
2.   STATUS: byte ABSOLUTE $03  RECORD C , DC, Z, PD, _TO : Bit; RP : 0..3; END;
3.  

This would not be a strange syntax for me to find in a microcontroller pascal compiler.

Good. Because I'm really thinking on implementing this syntax.

Heh, then you can take a look at old PICco for 16C6x, 16C7x and 16C8x. PICco is the father of AVRco. 
http://www.e-lab.de/PICco/index_en.html

Thanks for the link.  I need to check it.   
 

A lot of people in this thread have good intentions and nice ideas, but very few have worked with 8-bit microcontrollers to understand how much 36 bytes of RAM can limit your wishes for a compiler, and how much such limited resources influence compiler design.

Very true. Maybe I must use the title "Pascal-ish Syntax for very small devices Compiler for bit access."

Users would benefit if you treat bit type compatible with both 0/1 and true/false.

Actually, I have defined this types separately, and Incompatible. This is for security on types. See picture.

[Edson]

There are much more interesting questions like bit level normal variables (auto packed by compiler/linker). No absolute tricks necessary, just define as (multi) bit and let the compiler/linker pack them into bytes and access them using the bit instructions.

Currently, PicPas (my compiler) use only one bit for boolean/bit variables. It's necessary for save RAM. The compiler maintains a bitmap array for all the RAM available. When one byte is full, a new byte is used. 

And if I have an incoming (e.g. serial) buffer of say 20 bytes, how do I check  bit _TO in buffer[somevalue] ?

I haven't implemented arrays by now. I guess it's possible to do:

buffer[somevalue].4;

Or doing first:

AVariable_of_the_same_type_of_STATUS := buffer[somevalue];

With all due respect, but if you are limited to 36 bytes of ram then what the hell are you doing with a compiler.
Really, that is just a waste of time.

Tell this to the creators of CCS, SDCC, HITECH, MIkroC, MikroPascal, PBP,Pic Micro Pascal, ...
You really need to know more about the embedded world.

[molly]

Tell this to the creators of CCS, SDCC, HITECH, MIkroC, MikroPascal, PBP,Pic Micro Pascal, ...
You really need to know more about the embedded world.

That something can be done doesn't necessarely mean it is the way it should be done or that it is the best way.

Such compilers have their place when it makes sense. And again with all respect, it does not always make sense to use such compilers.

I have my experience with embedded hardware but, as soon as there are such limitations it is usually better to refrain from using compilers.and use assembler instead.

In situations were literally every bit counts, the human brain is much more intelligent then whatever compiler as a compiler has no notion of the overall picture of what it is that your code is accomplishing.

Hand made assembler routines that are specifically written for a specific task and for a specific device/processor can make use of all the optimizations that are possible for the architecture while a compiler is bound to take a generic approach, thereby wasting precious bits. Thus you are never able to reach the full potential of your controller when using a compiler.

Having said that, i understand that not everyone is up for learning opcodes, counting instruction cycles and understanding processor flags in order to make optimal use of these for a particular piece of code and for a particular device. That is where compilers (usually) come in, in order to take most of these burdens away from the developer.

Again, compilers targeting embedded devices have their use but imho not for all situations as there is such trade-off.

[avra]

Users would benefit if you treat bit type compatible with both 0/1 and true/false.

Actually, I have defined this types separately, and Incompatible. This is for security on types.

That's fine. I just prefer

Code: Pascal  [Select][+][-]

1. if (PinA.LswOn and not PinC.EmOn) then ...

over

Code: Pascal  [Select][+][-]

1. if (PinA.LswOn = 1) and (PinC.EmOn = 0) then ...

Both work 

[avra]

A lot of people in this thread have good intentions and nice ideas, but very few have worked with 8-bit microcontrollers to understand how much 36 bytes of RAM can limit your wishes for a compiler, and how much such limited resources influence compiler design. Anything that adds unnecessary overhead could render your compiler useless for some applications because you would run out of ram or flash space too soon. Then users will turn to C, and we wouldn't like that, would we?

With all due respect, but if you are limited to 36 bytes of ram then what the hell are you doing with a compiler.

Really, that is just a waste of time.

Just grab a good macro assembler and be done with the thing.

Well, if you search the net for Tiny AVR projects (these microcontrollers mostly have just 32 bytes of ram) you will see hundreds of projects (mostly written in GCC), and very little written in pure assembler (macro or not). People might use inline assembly in some of their projects (I used it for instance in a frame grabber to catch PAL video beam, for bit banging, or to achieve max speed for some kind of logic analyzer), but it's really not that often. Your mainboard fan controller is probably some small I2C based PIC or AVR. Your remote, your car key, keyboard controller, your rgb bulb, your smart home sensors and many other things probably have some small 8-bit MCU. Such small MCUs (especially with just 32 bytes of ram) are not as popular as they used to be 20 years ago, but they still have their place. Not every application needs an ARM. And not every time Linux is the best hammer. RTOS can also fit many types of nails, and smallest don't even need multitasking. With smart compiler you can develop for almost a generic MCU, and then make a final MCU cost optimized decision after you see how much ram or flash space your final application needs. Such small savings in quantity might decide if project is a winner or not. Using assembler instead of a compiler would make me tied to a specific MCU model more then I would like, I would loose too much time trying to implement some high level logic or stuff from datasheets and application notes, decrease readability and maintainability a lot, make debugging much harder, and in general slow me down by a factor of ten. Yes, I am aware that with smallest mentioned MCUs you can not have too complex software so difference is not that drastic in some aspects (in some it still is), but I would vote for a compiler over plain assembler any time.

Btw, there is AVR macro assembler written in FreePascal: http://www.avr-asm-tutorial.net/gavrasm/index_en.html