TIP #472: Add Support for 0d Radix Prefix to Integer Literals


TIP:472
Title:Add Support for 0d Radix Prefix to Integer Literals
Version:$Revision: 1.8 $
Authors: Venkat Iyer <venksi at gmail dot com>
Brian Griffin <brian_griffin at mentor dot com>
State:Accepted
Type:Project
Tcl-Version:8.7
Vote:Done
Created:Thursday, 25 May 2017

Abstract

This TIP proposes adding support for a 0d decimal radix prefix to complement the existing 0x hexidecimal, 0o octal and 0b binary radix prefixes.

Rationale

Verilog (and other Hardware Description Languages) always (or at least since the 1995 LRM) had a way to specify a decimal number explicitly. Verilog uses 'd343534 to mean decimal, VHDL actually allows any radix from 2 to 16 using syntax, so you could explicitly force a decimal interpretation using 10#343534#.

Tcl now allows 0b for binary in expr and format, which is similar to 'b in Verilog. And of course the 0x prefix has always been around. Another use case would be to prevent false parsing of leading zeroes in clock formats as octal, without having to go through a scan.

But a more elegant reason is that it makes the radix definition consistent, so

  1. all valid input radixes have a consistent unambiguous input literal format, and

  2. the d in format %d finally finds its complement in scan.

Specification

Extend the TclParseNumber function to recognize the prefixes 0d and 0D as decimal integers. It will have the same semantics as 0x, but base 10 instead of base 16.

Also extend format command '#' flag to produce the appropriate "0d" for the "%#d" conversion.

Examples

It's an integer:

   % expr {0d12 + 0d15}
   27
   % format "%#x" 0d1024
   0x400
   % format "%#d" 128
   0d128

Errors same as other radix prefixes:

   % expr { 0d317g }
   invalid bareword "0d317g"
   in expression " 0d317g ";
   should be "$0d317g" or "{0d317g}" or "0d317g(...)" or ...
   % expr { 0x1.53 }
   missing operator at [email protected]_
   in expression " [email protected]_.53 "
   % expr {0d7.23}
   missing operator at [email protected]_
   in expression "[email protected]_.23"

Compatibility

Currently, literals beginning with 0d and parsed as a number will produce an error. Any code expecting such an error would fail to produce an error an thus have a change in behavior. I would expect this situation to be uncommon.

Implementation

An implementation can be found the fossil on the "bsg-0d-radix-prefix" branch, including %#d conversion support.

Copyright

This document has been placed in the public domain.


Powered by Tcl[Index] [History] [HTML Format] [Source Format] [LaTeX Format] [Text Format] [XML Format] [*roff Format (experimental)] [RTF Format (experimental)]

TIP AutoGenerator - written by Donal K. Fellows