From: bc@freeuk.com
On 26/11/2025 23:04, BGB wrote:
> On 11/25/2025 5:38 AM, bart wrote:
>> On 25/11/2025 02:03, Keith Thompson wrote:
>>> bart writes:
>>>> On 24/11/2025 14:41, David Brown wrote:
>>>>> On 24/11/2025 13:31, bart wrote:
>>>>> That's all up to the implementation.
>>>>> You are worrying about completely negligible things here.
>>>>
>>>> Is it that negligible? That's easy to say when you're not doing the
>>>> implementing! However it may impact on the size and performance of
>>>> code.
>>>
>>> You're right, it's easy to say when I'm not doing the implementing.
>>> Which I'm not.
>>>
>>> The maintainers of gcc and llvm/clang have done that for me, so I don't
>>> have to worry about it.
>>>
>>> Are you planning to implement bit-precise integer types yourself? I
>>> don't think you've said so in this thread. If you are, you have at
>>> least two existing implementations you can look at for ideas.
>>
>> No, apart from the usual set of 8/16/32/64 bits. I've done 128 bits,
>> and played with 1/2/4 bits, but my view is that above this range,
>> using exact bit-sizes is the wrong way to go.
>>
>
> On normal PC's, it is meh.
>
> On FPGA's, more so the whole HLS (High Level Synthesis) thing, it is
> much more significant.
>
>
> Also it is a bridge that allows sensible mapping some Verilog semantics
> onto C, which can in turn be made more efficient than "ye olde shifts
> and masking". This is partly a case because the compiler has more
> freedom to either use specific CPU features, or to implement the
> constructs in ways that are more efficient but would impose too much
> mental computational burden on normal programmers (such as shifts being
> relative to other shifts, and/or where the most efficient masking
> strategy depends on the width of the type being masked, etc).
>
> Though, granted, bolting a bunch of Verilog stuff onto C is also
> nonstandard (and goes well beyond the scope of _BitInt). But, a lot of
> it is stuff that wouldn't really make sense at all in C in the absence
> of exact-width integers.
>
>
>
> Though, the other parts of Verilog don't map over quite so easily...
> always @(posedge clock)
> ...
> ... yeah ...
>
> Ironically, had started looking into adding Verilog support to my
> compiler (at the time hoping maybe to be able to implement something
> that was less of a pain to debug on than Verilator), most I got here was
> the idea that modules would be mapped onto classes and so each module
> could be implemented as a class instance, with an internal run/step
> method which would check variables and fire off any "always" blocks when
> appropriate.
>
> The effort kinda stalled out at this stage though (and motivation
> lessened when I actually found some of the bugs I had been looking for).
>
>
> Some other functionality had ended up mapped onto C, some features
> (ironically) being useful in this C land, and others not so much.
>
> Well, maybe some people could cheer for things like "casez()" or
> "__switchz()":
> __switchz(val[15:0])
> {
> case 0bZZZZ_ZZZZ_ZZZZ_ZZZ0u16: ... matches everything with LSB clear
> case 0bZZZZ_ZZZZ_ZZZZ_ZZ01u16: ... matches with LSB's as 01
> case 0bZZZZ_ZZZZ_ZZZZ_Z011u16: ...
> case 0b1111_ZZZZ_ZZZZ_0111u16: ... mastches 0111 and MSBs set to 1s.
> }
>
> Where, 0bZZZZ_ZZZZ_ZZZZ_Z011u16 is a C syntax analog of
> 16'bbZZZZ_ZZZZ_ZZZZ_Z011 (and in this case my compiler allows for either
> _ or single quotes).
>
>
>
> Though, implementing this in a way that is efficient is a harder problem
> (much more complicated than a normal "switch()").
>
> Though, had I gotten this part implemented, would still have also needed:
> A high performance emulator (now partly written, but, would likely need
> a full JIT compiler rather than a call-threading interpreter);
> A better/more usable debugger (*).
>
> *: My existing "jx2vm" emulator mostly dumps stuff if the emulator
> exits, and has an integrated GDB style debugger, this still leaves
> something to be desired.
>
> So, more likely the desired debugger would likely be built on "x3vm",
> but have not yet done so.
>
>
> Also compiler needs to produce more complete debuginfo. As-is, it is
> outputting symbol maps (in nm notation, similar to that typically used
> by the Linux kernel), with line-numbers in a slightly nonstandard way,
> and some small about of STABS. Maybe weak, but currently the most
> reachable strategy (contrast, GCC would typically put the debug info
> inside the binary, either as STABS or DWARF depending on target, ...).
> The debuginfo is still very incomplete, and I am also lacking a good
> debugger here.
>
> I had considered the possibility of going to a binary format for the map
> files to save space, but for now they are still ASCII based (well, or
> the possible lazier option of internally generating the map in ASCII
> format, but then dumping it in gzip format or similar ".map.gz"; would
> need to decompress them when loaded, but would leave an easy option for
> a user to get back to an ASCII map file as needed). Including STABS
> would add considerable bulk even vs just a normal symbol listing.
>
> I have my own reasons for not wanting to put debuginfo inside the
> binaries themselves. MSVC is kinda similar, just uses ".PDB" files instead.
>
>
>> While for odd sizes up to 64 bits, bitfields are more apt than
>> employing the type system.
>>
>
> This is missing the point of the purpose of _BitInt...
Which is ... ?
From what I can gether, on ordinary computers, Bitint(N), for N of 1/2
to 63, is just rounded up to the next size of 8/16/32/64 bits, if N is
not already at that size.
That's if storage is involved.
The other aspect appears to be two-fold:
* BitInt(N) used as a cast on an ordinary value will zero- or
sign-extend the low N bits
* When reading from storage allocated with BitInt(N), is ensures only N
bits of info are retrieved, extended as necessary, even of more then N
bits were stored. This applies even if the storage was rounded up.
So it seems to be mainly about masking.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
