From: cr88192@gmail.com
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...
>> Here's an idea. Rather than asserting that _BitInt(1'000'000)
>> is silly and obviously useless, try *asking* how it's useful.
>> I personally don't know what I'd do with a million-bit integer,
>> but maybe somebody out there has a valid use for it. Meanwhile,
>> its existence doesn't bother me.
>
> Again, my view is that types like _BitInt(123456) (could they have made
> it any more fiddly to type?!) is the same mistake that early Pascal made
> with arrays.
>
> It is common that an N-array of T and an M-array of T are not
> compatible, but usually there are ways to deal generically with both.
>
For using them in a way that is useful for their intended purpose, there
need to be some constraints here.
But, alas, debating 1M bit values is a little moot in my case as the
compiler doesn't go quite that big.
Most cases where a giant _BitInt could make sense are better served by
not using _BitInt.
In this case, the limit is 16383 bits, but this is still bigger than
anything it really makes sense to do with _BitInt.
Also doesn't make sense for Verilog either; about as soon as you start
trying to use values this big, it is "gonna eat the FPGA".
Well, and for things like bignums, could instead make a case for a
dynamic typesystem and the ability for user code to plug new types into
said dynamic typesystem (and register operators for said types).
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
